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 Sat, Oct 13, 2007 at 01:52:52AM -0700, Andrew Morton wrote:
> On Sat, 13 Oct 2007 10:44:55 +0200 Borislav Petkov <[EMAIL PROTECTED]> wrote:
>
> > can you please add http://lkml.org/lkml/2007/7/30/98 also to the misc-queue
> > for
> > the warning still persists and the patch is good to go as
On Sat, 13 Oct 2007 10:44:55 +0200 Borislav Petkov <[EMAIL PROTECTED]> wrote:
> can you please add http://lkml.org/lkml/2007/7/30/98 also to the misc-queue
> for
> the warning still persists and the patch is good to go as is (against current
> git
> v2.6.23-2840-g752097c, for example) albeit
On Mon, Oct 01, 2007 at 02:22:22PM -0700, Andrew Morton wrote:
> #increase-at_vector_size-to-terminate-saved_auxv-properly.patch: Tony wanted
> enhancements
> increase-at_vector_size-to-terminate-saved_auxv-properly.patch
> change-inotifyfs-magic-as-the-same-magic-is-used-for-futexfs-v2.patch
>
On Mon, Oct 01, 2007 at 02:22:22PM -0700, Andrew Morton wrote:
snip
#increase-at_vector_size-to-terminate-saved_auxv-properly.patch: Tony wanted
enhancements
increase-at_vector_size-to-terminate-saved_auxv-properly.patch
change-inotifyfs-magic-as-the-same-magic-is-used-for-futexfs-v2.patch
On Sat, 13 Oct 2007 10:44:55 +0200 Borislav Petkov [EMAIL PROTECTED] wrote:
can you please add http://lkml.org/lkml/2007/7/30/98 also to the misc-queue
for
the warning still persists and the patch is good to go as is (against current
git
v2.6.23-2840-g752097c, for example) albeit with a
On Sat, Oct 13, 2007 at 01:52:52AM -0700, Andrew Morton wrote:
On Sat, 13 Oct 2007 10:44:55 +0200 Borislav Petkov [EMAIL PROTECTED] wrote:
can you please add http://lkml.org/lkml/2007/7/30/98 also to the misc-queue
for
the warning still persists and the patch is good to go as is (against
Rik van Riel wrote:
> On Tue, 02 Oct 2007 09:51:11 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> I was hopeful of getting the bare minimal infrastructure for memory
>> control in mainline, so that review is easy and additional changes
>> can be well reviewed as well.
>
> I am not yet
Rik van Riel wrote:
On Tue, 02 Oct 2007 09:51:11 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
I was hopeful of getting the bare minimal infrastructure for memory
control in mainline, so that review is easy and additional changes
can be well reviewed as well.
I am not yet convinced that
On Tue, 02 Oct 2007 09:51:11 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> I was hopeful of getting the bare minimal infrastructure for memory
> control in mainline, so that review is easy and additional changes
> can be well reviewed as well.
I am not yet convinced that the way the memory
On Wed, 10 Oct 2007, Nick Piggin wrote:
>
> It just seems like now might be a good time to just _try_ removing
> the zero page
Yes. Let's do your patch immediately after the x86 merge, and just see if
anybody screams.
It might take a while, because I certainly agree that whoever would be
On Wednesday 10 October 2007 15:20, Linus Torvalds wrote:
> On Wed, 10 Oct 2007, Hugh Dickins wrote:
> > On Tue, 9 Oct 2007, Nick Piggin wrote:
> > > by it ;) To prove my point: the *first* approach I posted to fix this
> > > problem was exactly a patch to special-case the zero_page refcounting
>
On Wednesday 10 October 2007 15:20, Linus Torvalds wrote:
On Wed, 10 Oct 2007, Hugh Dickins wrote:
On Tue, 9 Oct 2007, Nick Piggin wrote:
by it ;) To prove my point: the *first* approach I posted to fix this
problem was exactly a patch to special-case the zero_page refcounting
which
On Wed, 10 Oct 2007, Nick Piggin wrote:
It just seems like now might be a good time to just _try_ removing
the zero page
Yes. Let's do your patch immediately after the x86 merge, and just see if
anybody screams.
It might take a while, because I certainly agree that whoever would be
On Tue, 02 Oct 2007 09:51:11 +0530
Balbir Singh [EMAIL PROTECTED] wrote:
I was hopeful of getting the bare minimal infrastructure for memory
control in mainline, so that review is easy and additional changes
can be well reviewed as well.
I am not yet convinced that the way the memory
On Wed, 10 Oct 2007, Hugh Dickins wrote:
> On Tue, 9 Oct 2007, Nick Piggin wrote:
> > by it ;) To prove my point: the *first* approach I posted to fix this
> > problem was exactly a patch to special-case the zero_page refcounting
> > which was removed with my PageReserved patch. Neither Hugh
On Tue, 9 Oct 2007, Nick Piggin wrote:
> by it ;) To prove my point: the *first* approach I posted to fix this
> problem was exactly a patch to special-case the zero_page refcounting
> which was removed with my PageReserved patch. Neither Hugh nor yourself
> liked it one bit!
True (speaking for
On Tue, 9 Oct 2007, Nick Piggin wrote:
>
> I gave 2 other numbers. After that, it really doesn't matter if I give
> you 2 numbers or 200, because it wouldn't change the fact that there
> are 3 programs using the ZERO_PAGE that we'll never know about.
You gave me no timings what-so-ever. Yes,
On Wednesday 10 October 2007 12:22, Linus Torvalds wrote:
> On Tue, 9 Oct 2007, Nick Piggin wrote:
> > Where do you suggest I go from here? Is there any way I can
> > convince you to try it? Make it a config option? (just kidding)
>
> No, I'll take the damn patch, but quite frankly, I think your
On Tue, 9 Oct 2007, Nick Piggin wrote:
>
> Where do you suggest I go from here? Is there any way I can
> convince you to try it? Make it a config option? (just kidding)
No, I'll take the damn patch, but quite frankly, I think your arguments
suck.
I've told you so before, and asked for
On Wednesday 10 October 2007 00:52, Linus Torvalds wrote:
> On Tue, 9 Oct 2007, Nick Piggin wrote:
> > I have done some tests which indicate a couple of very basic common tools
> > don't do much zero-page activity (ie. kbuild). And also combined with
> > some logical arguments to say that a "sane"
On Tue, 9 Oct 2007, Nick Piggin wrote:
>
> The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
>
> A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
> (and thus mapcounted and count towards shared rss). These writes to
> the struct page could cause
On Tue, 9 Oct 2007, Nick Piggin wrote:
>
> I have done some tests which indicate a couple of very basic common tools
> don't do much zero-page activity (ie. kbuild). And also combined with some
> logical arguments to say that a "sane" app wouldn't be using zero_page much.
> (basically -- if the
> r-o-bind-mounts-filesystem-helpers-for-custom-struct-files.patch
> r-o-bind-mounts-rearrange-may_open-to-be-r-o-friendly.patch
> r-o-bind-mounts-give-permission-a-local-mnt-variable.patch
> r-o-bind-mounts-create-cleanup-helper-svc_msnfs.patch
<...>
> Doesn't seem ready yet
I guess we need
On Thursday 04 October 2007 01:21, Linus Torvalds wrote:
> On Wed, 3 Oct 2007, Nick Piggin wrote:
> > I don't know if Linus actually disliked the patch itself, or disliked
> > my (maybe confusingly worded) rationale?
>
> Yes. I'd happily accept the patch, but I'd want it clarified and made
>
On Thursday 04 October 2007 01:21, Linus Torvalds wrote:
On Wed, 3 Oct 2007, Nick Piggin wrote:
I don't know if Linus actually disliked the patch itself, or disliked
my (maybe confusingly worded) rationale?
Yes. I'd happily accept the patch, but I'd want it clarified and made
obvious what
r-o-bind-mounts-filesystem-helpers-for-custom-struct-files.patch
r-o-bind-mounts-rearrange-may_open-to-be-r-o-friendly.patch
r-o-bind-mounts-give-permission-a-local-mnt-variable.patch
r-o-bind-mounts-create-cleanup-helper-svc_msnfs.patch
...
Doesn't seem ready yet
I guess we need some
On Tue, 9 Oct 2007, Nick Piggin wrote:
I have done some tests which indicate a couple of very basic common tools
don't do much zero-page activity (ie. kbuild). And also combined with some
logical arguments to say that a sane app wouldn't be using zero_page much.
(basically -- if the app
On Tue, 9 Oct 2007, Nick Piggin wrote:
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive
On Wednesday 10 October 2007 00:52, Linus Torvalds wrote:
On Tue, 9 Oct 2007, Nick Piggin wrote:
I have done some tests which indicate a couple of very basic common tools
don't do much zero-page activity (ie. kbuild). And also combined with
some logical arguments to say that a sane app
On Tue, 9 Oct 2007, Nick Piggin wrote:
Where do you suggest I go from here? Is there any way I can
convince you to try it? Make it a config option? (just kidding)
No, I'll take the damn patch, but quite frankly, I think your arguments
suck.
I've told you so before, and asked for numbers,
On Wednesday 10 October 2007 12:22, Linus Torvalds wrote:
On Tue, 9 Oct 2007, Nick Piggin wrote:
Where do you suggest I go from here? Is there any way I can
convince you to try it? Make it a config option? (just kidding)
No, I'll take the damn patch, but quite frankly, I think your
On Tue, 9 Oct 2007, Nick Piggin wrote:
I gave 2 other numbers. After that, it really doesn't matter if I give
you 2 numbers or 200, because it wouldn't change the fact that there
are 3 programs using the ZERO_PAGE that we'll never know about.
You gave me no timings what-so-ever. Yes, you
On Tue, 9 Oct 2007, Nick Piggin wrote:
by it ;) To prove my point: the *first* approach I posted to fix this
problem was exactly a patch to special-case the zero_page refcounting
which was removed with my PageReserved patch. Neither Hugh nor yourself
liked it one bit!
True (speaking for me; I
On Wed, 10 Oct 2007, Hugh Dickins wrote:
On Tue, 9 Oct 2007, Nick Piggin wrote:
by it ;) To prove my point: the *first* approach I posted to fix this
problem was exactly a patch to special-case the zero_page refcounting
which was removed with my PageReserved patch. Neither Hugh nor
Hugh Dickins wrote:
> On Fri, 5 Oct 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>> That's where it should happen, yes; but my point is that it very
>>> often does not. Because the swap cache page (read in as part of
>>> the readaround cluster of some other cgroup, or in swapoff by some
>>>
On Fri, 5 Oct 2007, Balbir Singh wrote:
> Hugh Dickins wrote:
> >
> > That's where it should happen, yes; but my point is that it very
> > often does not. Because the swap cache page (read in as part of
> > the readaround cluster of some other cgroup, or in swapoff by some
> > other cgroup) is
On Fri, 5 Oct 2007, Balbir Singh wrote:
Hugh Dickins wrote:
That's where it should happen, yes; but my point is that it very
often does not. Because the swap cache page (read in as part of
the readaround cluster of some other cgroup, or in swapoff by some
other cgroup) is already
Hugh Dickins wrote:
On Fri, 5 Oct 2007, Balbir Singh wrote:
Hugh Dickins wrote:
That's where it should happen, yes; but my point is that it very
often does not. Because the swap cache page (read in as part of
the readaround cluster of some other cgroup, or in swapoff by some
other cgroup)
Hugh Dickins wrote:
> On Thu, 4 Oct 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>> Well, swap control is another subject. I guess for that you'll need
>>> to track which cgroup each swap page belongs to (rather more expensive
>>> than the current swap_map of unsigned shorts). And I doubt
On 10/2/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> I accept that full swap control is something you're intending to add
> incrementally later; but the current state doesn't make sense to me.
One comment on swap - ideally it should be a separate subsystem from
the memory controller. That way
On Thu, 4 Oct 2007, Balbir Singh wrote:
> Hugh Dickins wrote:
> > Well, swap control is another subject. I guess for that you'll need
> > to track which cgroup each swap page belongs to (rather more expensive
> > than the current swap_map of unsigned shorts). And I doubt it'll be
> > swap
On Thu, 4 Oct 2007, Balbir Singh wrote:
Hugh Dickins wrote:
Well, swap control is another subject. I guess for that you'll need
to track which cgroup each swap page belongs to (rather more expensive
than the current swap_map of unsigned shorts). And I doubt it'll be
swap control as such
On 10/2/07, Hugh Dickins [EMAIL PROTECTED] wrote:
I accept that full swap control is something you're intending to add
incrementally later; but the current state doesn't make sense to me.
One comment on swap - ideally it should be a separate subsystem from
the memory controller. That way
Hugh Dickins wrote:
On Thu, 4 Oct 2007, Balbir Singh wrote:
Hugh Dickins wrote:
Well, swap control is another subject. I guess for that you'll need
to track which cgroup each swap page belongs to (rather more expensive
than the current swap_map of unsigned shorts). And I doubt it'll be
Hugh Dickins wrote:
> On Wed, 3 Oct 2007, Balbir Singh wrote:
>> Hugh Dickins wrote:
>>> Sorry, Balbir, I've failed to get back to you, still attending to
>>> priorities. Let me briefly summarize my issue with the mem controller:
>>> you've not yet given enough attention to swap.
>> I am open to
Andrew-
Could you please add the trace patches to the merge list?
These patches have been very well reviewed on lkml. I believe they are
ready to be merged. The patches can be found here:
http://lkml.org/lkml/2007/10/2/236
http://lkml.org/lkml/2007/10/2/237
http://lkml.org/lkml/2007/10/2/238
On Wed, 3 Oct 2007, Balbir Singh wrote:
> Hugh Dickins wrote:
> >
> > Sorry, Balbir, I've failed to get back to you, still attending to
> > priorities. Let me briefly summarize my issue with the mem controller:
> > you've not yet given enough attention to swap.
>
> I am open to suggestions and
On Wed, 3 Oct 2007, Nick Piggin wrote:
>
> I don't know if Linus actually disliked the patch itself, or disliked
> my (maybe confusingly worded) rationale?
Yes. I'd happily accept the patch, but I'd want it clarified and made
obvious what the problem was - and it wasn't the zero page itself,
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:
> >
1 - 100 of 200 matches
Mail list logo
