Yeah, I thought we were told off in the past for not using centisecs
and so Nathan changed stuff so it was in centisecs.
Looking in logs and bug db....
date: 2004/05/14 03:13:52; author: nathans; state: Exp; lines: +7 -7
Export/import tunable time intervals as centisecs not jiffies.
Not sure what we were smoking when we made these interfaces
converse with userspace in terms of jiffies, I guess it was
just more expedient at the time. Time to clean this up so
regular humans know what time intervals they're asking for,
and so that the interface works consistently for different
The kernel pdflush daemon in 2.6 uses centisecs, so we may
as well make our units consistent with that (since that guy
plays a big role in flushing our data & it is likely to be
tuned along with any XFS-specific parameter changes).
On Tue, May 11, 2004 at 03:40:57PM -0700, Andrew Morton wrote:
> The laptop mode control script incorrectly guesses XFS_HZ=1000.
aargh. XFS is broken. It shouldn't be exposing jiffy-based tunables into
/proc, or `mount -o remount' or whatever.
It would be much better to rework XFS so that these user-visible tunables
are in units of milliseconds, centiseconds or whatever.
Is this possible, please?
If so, please make the /proc filename reflect the tunable's units:
--On 12 May 2007 10:08:56 PM -0500 Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
Andi Kleen wrote:
Also centisecs is a really ugly unit whose use should be probably not
Hmm at one point I thought the preferred unit for this sort of tuneable
*was* centisecs. What's
the unit du jour?
[root@neon ~]# sysctl -a |grep cent
vm.dirty_expire_centisecs = 2999
vm.dirty_writeback_centisecs = 499
fs.xfs.age_buffer_centisecs = 1500
fs.xfs.xfsbufd_centisecs = 100
fs.xfs.xfssyncd_centisecs = 3000
I think xfs was following the vm lead at one point.