On Fri, 2007-12-14 at 16:14 +0100, Miklos Szeredi wrote:
> > Neil suggested using device numbers which would work, however I think
> > those might not be human friendly. While its easy to find the device
> > number of a given path (eg.: stat -c %d /), its rather hard to find the
> > path
> Neil suggested using device numbers which would work, however I think
> those might not be human friendly. While its easy to find the device
> number of a given path (eg.: stat -c %d /), its rather hard to find the
> path belonging to a given device number.
Ram Pai had a patch which added the
On Fri, 2007-10-26 at 12:37 -0400, Trond Myklebust wrote:
> On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
>
> > Miklos, Trond: could you suggest a better fmt for the bdi_init_fmt() for
> > your
> > respective filesystems?
>
> > Index: linux-2.6-2/fs/nfs/client.c
> >
On Fri, 2007-10-26 at 12:37 -0400, Trond Myklebust wrote:
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
Miklos, Trond: could you suggest a better fmt for the bdi_init_fmt() for
your
respective filesystems?
snip
Index: linux-2.6-2/fs/nfs/client.c
Neil suggested using device numbers which would work, however I think
those might not be human friendly. While its easy to find the device
number of a given path (eg.: stat -c %d /), its rather hard to find the
path belonging to a given device number.
Ram Pai had a patch which added the
On Fri, 2007-12-14 at 16:14 +0100, Miklos Szeredi wrote:
Neil suggested using device numbers which would work, however I think
those might not be human friendly. While its easy to find the device
number of a given path (eg.: stat -c %d /), its rather hard to find the
path belonging to a
On Fri, 2007-11-02 at 15:17 +0100, Peter Zijlstra wrote:
> One more question,
>
> I currently prefix the names with "bdi-", is that needed?
Not really.
> That is, if I give the bdi object a parent, how will it look?
> Would a bdi device with name "sda" with a block device called "sda" as
>
One more question,
I currently prefix the names with "bdi-", is that needed?
That is, if I give the bdi object a parent, how will it look?
Would a bdi device with name "sda" with a block device called "sda" as
parent look like: /sys/block/sda/sda? Or would if be
called /sys/block/sda/bdi:sda or
On Fri, 2007-11-02 at 14:50 +0100, Kay Sievers wrote:
> On Nov 2, 2007 2:15 PM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > Thanks for the help so far, however we're still not quite there.
> >
> > The below patch still has the funny 20 character name limit. Is there a
> > good reason its a char
On Nov 2, 2007 2:15 PM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Thanks for the help so far, however we're still not quite there.
>
> The below patch still has the funny 20 character name limit. Is there a
> good reason its a char array like this, and not just a char * to a kstr?
> The code
Hi,
Thanks for the help so far, however we're still not quite there.
The below patch still has the funny 20 character name limit. Is there a
good reason its a char array like this, and not just a char * to a kstr?
The code does kstrdup all over the place, I can't imagine why suddenly
limiting it
One more question,
I currently prefix the names with bdi-, is that needed?
That is, if I give the bdi object a parent, how will it look?
Would a bdi device with name sda with a block device called sda as
parent look like: /sys/block/sda/sda? Or would if be
called /sys/block/sda/bdi:sda or just
On Fri, 2007-11-02 at 15:17 +0100, Peter Zijlstra wrote:
One more question,
I currently prefix the names with bdi-, is that needed?
Not really.
That is, if I give the bdi object a parent, how will it look?
Would a bdi device with name sda with a block device called sda as
parent look
On Fri, 2007-11-02 at 14:50 +0100, Kay Sievers wrote:
On Nov 2, 2007 2:15 PM, Peter Zijlstra [EMAIL PROTECTED] wrote:
Thanks for the help so far, however we're still not quite there.
The below patch still has the funny 20 character name limit. Is there a
good reason its a char array like
On Nov 2, 2007 2:15 PM, Peter Zijlstra [EMAIL PROTECTED] wrote:
Thanks for the help so far, however we're still not quite there.
The below patch still has the funny 20 character name limit. Is there a
good reason its a char array like this, and not just a char * to a kstr?
The code does
Hi,
Thanks for the help so far, however we're still not quite there.
The below patch still has the funny 20 character name limit. Is there a
good reason its a char array like this, and not just a char * to a kstr?
The code does kstrdup all over the place, I can't imagine why suddenly
limiting it
On Sat, Oct 27, 2007 at 11:35:45PM +0200, Peter Zijlstra wrote:
> On Sat, 2007-10-27 at 23:08 +0200, Kay Sievers wrote:
> > All this open-coded attribute stuff should go away and be replaced by:
> > bdi_class->dev_attrs = bdi_dev_attrs;
> > Otherwise at event time the attributes are not created
On Sat, Oct 27, 2007 at 11:35:45PM +0200, Peter Zijlstra wrote:
On Sat, 2007-10-27 at 23:08 +0200, Kay Sievers wrote:
All this open-coded attribute stuff should go away and be replaced by:
bdi_class-dev_attrs = bdi_dev_attrs;
Otherwise at event time the attributes are not created and
On Sat, 2007-10-27 at 23:08 +0200, Kay Sievers wrote:
> On Sat, 2007-10-27 at 09:02 -0700, Greg KH wrote:
> > Ah, I see a few problems. Here, try this version instead. It's
> > compile-tested only, and should be a lot simpler.
> >
> > Note, we still are not setting the parent to the new bdi
On Sat, 2007-10-27 at 09:02 -0700, Greg KH wrote:
> On Sat, Oct 27, 2007 at 10:39:59AM +0200, Peter Zijlstra wrote:
> > On Fri, 2007-10-26 at 19:40 -0700, Greg KH wrote:
> > > On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
> > > > On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra
On Sat, 2007-10-27 at 09:02 -0700, Greg KH wrote:
> Ah, I see a few problems. Here, try this version instead. It's
> compile-tested only, and should be a lot simpler.
>
> Note, we still are not setting the parent to the new bdi structure
> properly, so the devices will show up in
On Sat, Oct 27, 2007 at 10:39:59AM +0200, Peter Zijlstra wrote:
> On Fri, 2007-10-26 at 19:40 -0700, Greg KH wrote:
> > On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
> > >
> > > On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
> > > > This crashes and burns on bootup,
On Fri, 2007-10-26 at 19:40 -0700, Greg KH wrote:
> On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
> >
> > On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
> > > This crashes and burns on bootup, but I'm too tired to figure out what I
> > > did wrong... will give it
On Fri, 2007-10-26 at 19:40 -0700, Greg KH wrote:
On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
This crashes and burns on bootup, but I'm too tired to figure out what I
did wrong... will give it another try
On Sat, Oct 27, 2007 at 10:39:59AM +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 19:40 -0700, Greg KH wrote:
On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
This crashes and burns on bootup, but I'm too
On Sat, 2007-10-27 at 09:02 -0700, Greg KH wrote:
Ah, I see a few problems. Here, try this version instead. It's
compile-tested only, and should be a lot simpler.
Note, we still are not setting the parent to the new bdi structure
properly, so the devices will show up in
On Sat, 2007-10-27 at 09:02 -0700, Greg KH wrote:
On Sat, Oct 27, 2007 at 10:39:59AM +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 19:40 -0700, Greg KH wrote:
On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
On Sat, 2007-10-27 at 23:08 +0200, Kay Sievers wrote:
On Sat, 2007-10-27 at 09:02 -0700, Greg KH wrote:
Ah, I see a few problems. Here, try this version instead. It's
compile-tested only, and should be a lot simpler.
Note, we still are not setting the parent to the new bdi structure
On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
>
> On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
> > This crashes and burns on bootup, but I'm too tired to figure out what I
> > did wrong... will give it another try tomorrow..
>
> Ok, can't sleep.. took a look. I have
On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
> This crashes and burns on bootup, but I'm too tired to figure out what I
> did wrong... will give it another try tomorrow..
Ok, can't sleep.. took a look. I have several problems here.
The thing that makes it go *boom* is the
This crashes and burns on bootup, but I'm too tired to figure out what I
did wrong... will give it another try tomorrow..
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
block/genhd.c |2
fs/fuse/inode.c |2
fs/nfs/client.c |2
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
> Miklos, Trond: could you suggest a better fmt for the bdi_init_fmt() for your
> respective filesystems?
> Index: linux-2.6-2/fs/nfs/client.c
> ===
> ---
On Fri, 2007-10-26 at 17:33 +0200, Peter Zijlstra wrote:
> On Fri, 2007-10-26 at 17:33 +0200, Kay Sievers wrote:
> > On Fri, 2007-10-26 at 17:22 +0200, Peter Zijlstra wrote:
> > > On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
> > > > On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra
On Fri, 2007-10-26 at 17:33 +0200, Kay Sievers wrote:
> On Fri, 2007-10-26 at 17:22 +0200, Peter Zijlstra wrote:
> > On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
> > > On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
> > >
> > > > I appreciate the sysfs people their opinion that
On Fri, 2007-10-26 at 17:22 +0200, Peter Zijlstra wrote:
> On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
> > On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
> >
> > > I appreciate the sysfs people their opinion that /sys/bdi/ might not be
> > > the
> > > best from their POV,
On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
> On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
>
> > I appreciate the sysfs people their opinion that /sys/bdi/ might not be the
> > best from their POV, however I'm not seeing where to hook the BDI object
> > from
> > so that it
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
> I appreciate the sysfs people their opinion that /sys/bdi/ might not be the
> best from their POV, however I'm not seeing where to hook the BDI object from
> so that it all makes sense, a few of the things are currently not exposed in
>
> Subject: bdi: debugfs interface
>
> Expose the BDI stats (and readahead window) in /debug/bdi/
>
> I'm still thinking it should go into /sys somewhere, however I just noticed
> not all block devices that have a queue have a /queue directory. Noticeably
> those that use make_request_fn() as
On Wed, 2007-10-03 at 15:35 +0200, Kay Sievers wrote:
> On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
> > On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
> > > On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> > > > On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
> >
On Wed, 2007-10-03 at 15:35 +0200, Kay Sievers wrote:
On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue,
Subject: bdi: debugfs interface
Expose the BDI stats (and readahead window) in /debug/bdi/
I'm still thinking it should go into /sys somewhere, however I just noticed
not all block devices that have a queue have a /queue directory. Noticeably
those that use make_request_fn() as opposed to
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
I appreciate the sysfs people their opinion that /sys/bdi/ might not be the
best from their POV, however I'm not seeing where to hook the BDI object from
so that it all makes sense, a few of the things are currently not exposed in
sysfs
On Fri, 2007-10-26 at 17:22 +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
I appreciate the sysfs people their opinion that /sys/bdi/ might not be
the
best from their POV, however I'm not
On Fri, 2007-10-26 at 17:33 +0200, Kay Sievers wrote:
On Fri, 2007-10-26 at 17:22 +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
I appreciate the sysfs people their opinion that /sys/bdi/
On Fri, 2007-10-26 at 17:33 +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 17:33 +0200, Kay Sievers wrote:
On Fri, 2007-10-26 at 17:22 +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
I appreciate the sysfs people their opinion that /sys/bdi/ might not be the
best from their POV, however I'm not seeing where to hook the BDI object
from
so that it all makes
On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
Miklos, Trond: could you suggest a better fmt for the bdi_init_fmt() for your
respective filesystems?
snip
Index: linux-2.6-2/fs/nfs/client.c
===
---
This crashes and burns on bootup, but I'm too tired to figure out what I
did wrong... will give it another try tomorrow..
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
block/genhd.c |2
fs/fuse/inode.c |2
fs/nfs/client.c |2
On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
This crashes and burns on bootup, but I'm too tired to figure out what I
did wrong... will give it another try tomorrow..
Ok, can't sleep.. took a look. I have several problems here.
The thing that makes it go *boom* is the __ATTR_NULL.
On Sat, Oct 27, 2007 at 03:18:08AM +0200, Peter Zijlstra wrote:
On Fri, 2007-10-26 at 22:04 +0200, Peter Zijlstra wrote:
This crashes and burns on bootup, but I'm too tired to figure out what I
did wrong... will give it another try tomorrow..
Ok, can't sleep.. took a look. I have several
On Wed, 2007-10-03 at 15:35 +0200, Kay Sievers wrote:
> On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
> > On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
> > > On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> > > > On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
>
On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
> On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
> > On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> > > On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
> > > > On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> >
--- Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
>
> > nfs-remove-congestion_end.patch
> > lib-percpu_counter_add.patch
> > lib-percpu_counter_sub.patch
> > lib-percpu_counter-variable-batch.patch
> >
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
> On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> > On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
> > > On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> >
> > > > How about adding this information to the tree then,
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
> > On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
>
> > > How about adding this information to the tree then, instead of
> > > creating a new top-level hack, just because
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
How about adding this information to the tree then, instead of
creating a new top-level hack, just because something that
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
How about adding this information to the tree then, instead of
--- Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
lib-make-percpu_counter_add-take-s64.patch
On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
How
On Wed, 2007-10-03 at 15:35 +0200, Kay Sievers wrote:
On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue,
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
> On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> > How about adding this information to the tree then, instead of
> > creating a new top-level hack, just because something that you think
> > you need doesn't exist.
>
> So you
On 10/2/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> > On 10/2/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
> > >
> > > > What would be the point in another top-level tree for
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> On 10/2/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
> >
> > > What would be the point in another top-level tree for device
> > > information? All devices you are exporting
On Tue, Oct 02, 2007 at 01:22:32PM +0200, Kay Sievers wrote:
> On 10/2/07, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 02, 2007 at 12:44:21PM +0200, Peter Zijlstra wrote:
> > > On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
> > >
> > > > What would be the point in another
On 10/2/07, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 02, 2007 at 12:44:21PM +0200, Peter Zijlstra wrote:
> > On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
> >
> > > What would be the point in another top-level tree for device
> > > information? All devices you are exporting
On 10/2/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
>
> > What would be the point in another top-level tree for device
> > information? All devices you are exporting information for, are
> > already in the sysfs tree, right?
>
> Never did
On Tue, Oct 02, 2007 at 12:44:21PM +0200, Peter Zijlstra wrote:
> On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
>
> > What would be the point in another top-level tree for device
> > information? All devices you are exporting information for, are
> > already in the sysfs tree, right?
>
>
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
> What would be the point in another top-level tree for device
> information? All devices you are exporting information for, are
> already in the sysfs tree, right?
Never did find NFS mounts/servers/superblocks or whatever constitutes a
BDI
On 10/2/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-02 at 01:31 -0700, Andrew Morton wrote:
> > On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
> > >
> > > >
On Tue, 2007-10-02 at 01:31 -0700, Andrew Morton wrote:
> On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
> >
> > > nfs-remove-congestion_end.patch
> > > lib-percpu_counter_add.patch
> > >
On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
>
> > nfs-remove-congestion_end.patch
> > lib-percpu_counter_add.patch
> > lib-percpu_counter_sub.patch
> > lib-percpu_counter-variable-batch.patch
> >
On Tue, Oct 02, 2007 at 10:17:05AM +0200, Peter Zijlstra wrote:
> On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
>
> > nfs-remove-congestion_end.patch
> > lib-percpu_counter_add.patch
> > lib-percpu_counter_sub.patch
> > lib-percpu_counter-variable-batch.patch
> >
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
> nfs-remove-congestion_end.patch
> lib-percpu_counter_add.patch
> lib-percpu_counter_sub.patch
> lib-percpu_counter-variable-batch.patch
> lib-make-percpu_counter_add-take-s64.patch
> lib-percpu_counter_set.patch
>
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
lib-make-percpu_counter_add-take-s64.patch
lib-percpu_counter_set.patch
On Tue, Oct 02, 2007 at 10:17:05AM +0200, Peter Zijlstra wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
lib-percpu_counter-variable-batch.patch
On Tue, 2007-10-02 at 01:31 -0700, Andrew Morton wrote:
On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
lib-percpu_counter_add.patch
lib-percpu_counter_sub.patch
On 10/2/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 01:31 -0700, Andrew Morton wrote:
On Tue, 02 Oct 2007 10:17:05 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
nfs-remove-congestion_end.patch
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
information? All devices you are exporting information for, are
already in the sysfs tree, right?
Never did find NFS mounts/servers/superblocks or whatever constitutes a
BDI for
On Tue, Oct 02, 2007 at 12:44:21PM +0200, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
information? All devices you are exporting information for, are
already in the sysfs tree, right?
Never did
On 10/2/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
information? All devices you are exporting information for, are
already in the sysfs tree, right?
Never did find NFS
On 10/2/07, Fengguang Wu [EMAIL PROTECTED] wrote:
On Tue, Oct 02, 2007 at 12:44:21PM +0200, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
information? All devices you are exporting information
On Tue, Oct 02, 2007 at 01:22:32PM +0200, Kay Sievers wrote:
On 10/2/07, Fengguang Wu [EMAIL PROTECTED] wrote:
On Tue, Oct 02, 2007 at 12:44:21PM +0200, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
On 10/2/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
information? All devices you are exporting information for, are
On 10/2/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
On 10/2/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
What would be the point in another top-level tree for device
On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
How about adding this information to the tree then, instead of
creating a new top-level hack, just because something that you think
you need doesn't exist.
So you suggest adding
86 matches
Mail list logo
