On Thu, 2008-01-31 at 01:54 -0800, Andrew Morton wrote:

On Thu, 31 Jan 2008 10:39:02 +0100 Miklos Szeredi [off-list ref] wrote:

quoted

quoted

On Tue, 29 Jan 2008 16:49:02 +0100
Miklos Szeredi [off-list ref] wrote:

quoted

From: Peter Zijlstra <redacted>

Provide a place in sysfs (/sys/class/bdi) for the backing_dev_info
object.  This allows us to see and set the various BDI specific
variables.

In particular this properly exposes the read-ahead window for all
relevant users and /sys/block/<block>/queue/read_ahead_kb should be
deprecated.

This description is not complete.  It implies that the readahead window is
not "properly" exposed for some "relevant" users.  The reader is left
wondering what on earth this is referring to.  I certainly don't know.
Perhaps when this information is revealed, we can work out what was
wrong with per-queue readahead tuning.

I think Peter meant, that the readahead window was only exposed for
block devices, and not things like NFS or FUSE.

OK.

And queue-less block devices like loop-back md/dm and whatnot.

quoted

quoted

quoted

+blk-NAME
+
+	Block devices, NAME is 'sda', 'loop0', etc...

But if I've done `mknod /dev/pizza-party 8 0', I'm looking for
blk-pizza-party, not blk-sda.

But I might still have /dev/sda, too.

An alternative would be to uniformly use MAJOR:MINOR in there.  It
would work for block devices and anonymous devices (NFS/FUSE) as well.

Would that be any better?

I suppose so.  sysfs likes to use symlinks to point over at related
things in different directories...

Yeah, I think that would work best. Its more consistent as well.

quoted

quoted

quoted

+FSTYPE-MAJOR:MINOR
+
+	Non-block device backed filesystems which provide their own
+	BDI, such as NFS and FUSE.  MAJOR:MINOR is the value of st_dev
+	for files on this filesystem.
+
+default
+
+	The default backing dev, used for non-block device backed
+	filesystems which do not provide their own BDI.
+
+Files under /sys/class/bdi/<bdi>/
+---------------------------------
+
+read_ahead_kb (read-write)
+
+	Size of the read-ahead window in kilobytes
+
+reclaimable_kb (read-only)
+
+	Reclaimable (dirty or unstable) memory destined for writeback
+	to this device
+
+writeback_kb (read-only)
+
+	Memory currently under writeback to this device
+
+dirty_kb (read-only)
+
+	Global threshold for reclaimable + writeback memory
+
+bdi_dirty_kb (read-only)
+
+	Current threshold on this BDI for reclaimable + writeback
+	memory
+

I dunno.  A number of the things which you're exposing are closely tied to
present-day kernel implementation and may be irrelevant or even
unimplementable in a few years' time.

Which ones?

I don't know - I misplaced my copy of linux-2.6.44 :)

The whole concept of a BDI might go away, who knows?  Progress in
non-volatile semiconductor storage might make the whole
rotating-platter-with-a-seek-head thing obsolete.

read_ahead_kb is likely to be stable.  writeback_kb is a stable concept
too, although we might lose the ability to keep track of it some time in
the future.

Suppose that /dev/sda and /dev/sdb share the same queue - we lose the ability
to track some of these things?

quoted

 They could possibly be moved to debugfs, or something.

I agree, that sysfs should be relatively stable.

This does look more like a debugging feature than a permanently-offered,
support-it-forever part of the kernel ABI.

Agreed, all except the read_ahead tunable are debugish. The min/max
things are real tunables though. (writing up a little text on the
why/how of those as we speak - well, write)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>