LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	kay.sievers@vrfy.org, greg@kroah.com, trond.myklebust@fys.uio.no
Subject: Re: [patch 2/6] mm: bdi: export BDI attributes in sysfs
Date: Wed, 30 Jan 2008 16:28:39 -0800	[thread overview]
Message-ID: <20080130162839.977d1e63.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080129154948.823761079@szeredi.hu>

On Tue, 29 Jan 2008 16:49:02 +0100
Miklos Szeredi <miklos@szeredi.hu> wrote:

> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> 
> 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.

> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ linux/Documentation/ABI/testing/sysfs-class-bdi	2008-01-29 13:02:46.000000000 +0100
> @@ -0,0 +1,50 @@
> +What:		/sys/class/bdi/<bdi>/
> +Date:		January 2008
> +Contact:	Peter Zijlstra <a.p.zijlstra@chello.nl>
> +Description:
> +
> +Provide a place in sysfs for the backing_dev_info object.
> +This allows us to see and set the various BDI specific variables.
> +
> +The <bdi> identifyer can take the following forms:

"identifier"

> +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.

> +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.

At the very least you should put a HUGE warning in here telling everyone
that these files may disappear or be renamed with new semantics in the
future, and that they should design their userspace code with this in mind.

But that will only prevent userspace from outright crashing.  Once we
expose functionality of this nature, people will come to depend upon it.
We can't stop this.

Suppose $CLUELESS_CORP modifies $LARGE_DATABASE so that it uses these new
fields to optimise its cache population and cache flushout strategies. 
Later, we are forced to remove these fields.  The database now runs all
slowly.

It's just a bad idea to expose deep kernelguts in this way.  We need really
good reasons for doing so, and those reasons should be in the changelog.


  parent reply	other threads:[~2008-01-31  0:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29 15:49 [patch 0/6] mm: bdi: updates Miklos Szeredi
2008-01-29 15:49 ` [patch 1/6] mm: bdi: tweak task dirty penalty Miklos Szeredi
2008-01-31  0:13   ` Andrew Morton
2008-01-29 15:49 ` [patch 2/6] mm: bdi: export BDI attributes in sysfs Miklos Szeredi
2008-01-29 17:39   ` Greg KH
2008-01-31  0:28   ` Andrew Morton [this message]
2008-01-31  9:39     ` Miklos Szeredi
2008-01-31  9:54       ` Andrew Morton
2008-01-31 10:08         ` Peter Zijlstra
2008-02-29 11:26   ` Andrew Morton
2008-01-29 15:49 ` [patch 3/6] mm: bdi: expose the BDI object in sysfs for NFS Miklos Szeredi
2008-01-29 15:49 ` [patch 4/6] mm: bdi: expose the BDI object in sysfs for FUSE Miklos Szeredi
2008-01-29 15:49 ` [patch 5/6] mm: bdi: allow setting a minimum for the bdi dirty limit Miklos Szeredi
2008-01-29 15:49 ` [patch 6/6] mm: bdi: allow setting a maximum " Miklos Szeredi
2008-01-31  0:39   ` Andrew Morton
2008-01-31  9:46     ` Miklos Szeredi
2008-01-31 10:17       ` Peter Zijlstra
2008-01-29 17:06 ` [patch 0/6] mm: bdi: updates Peter Zijlstra
2008-01-29 18:32   ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080130162839.977d1e63.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=trond.myklebust@fys.uio.no \
    --subject='Re: [patch 2/6] mm: bdi: export BDI attributes in sysfs' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).