Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo before and after the updatedb run with the latest kernel would be a first step. top and vmstat output during the run wouldn't hurt either. Hi Nick,

Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo before and after the updatedb run with the latest kernel would be a first step. top and vmstat output during the run wouldn't hurt either. Hi Nick,

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo > before and after the updatedb run with the latest kernel would be a > first step. top and vmstat output during the run wouldn't hurt either. Hi Nick, I've attached two files

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo before and after the updatedb run with the latest kernel would be a first step. top and vmstat output during the run wouldn't hurt either. Hi Nick, I've attached two files with

Re: [ck] Re: -mm merge plans for 2.6.23

On Thu, 26 Jul 2007, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007, Jeff Garzik wrote: > Dirk Schoebel wrote: > > as long as the maintainer follows the kernel development things can > > be > > left in, if the maintainer can't follow anymore they are taken out > >

Re: [ck] Re: -mm merge plans for 2.6.23

[EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007, Jeff Garzik wrote: Dirk Schoebel wrote: as long as the maintainer follows the kernel development things can be left in, if the maintainer can't follow anymore they are taken out quite fast again. (This statement mostly counts for parts of the

Re: [ck] Re: -mm merge plans for 2.6.23

On Thu, 26 Jul 2007, Jeff Garzik wrote: Dirk Schoebel wrote: as long as the maintainer follows the kernel development things can be left in, if the maintainer can't follow anymore they are taken out quite fast again. (This statement mostly counts for parts of the kernel where a choice is

Re: [ck] Re: -mm merge plans for 2.6.23

Dirk Schoebel wrote: as long as the maintainer follows the kernel development things can be left in, if the maintainer can't follow anymore they are taken out quite fast again. (This statement mostly counts for parts of the kernel where a choice is possible or the coding overhead of making

Re: [ck] Re: -mm merge plans for 2.6.23

...sorry for the reply to myself. As Gentoo user i'm happy about the freedom of choice in almost every aspect of the system. But with the kernel this freedom is taken away and i'm left with largely choices other people did. Sure, i can get the sources and patch and change the kernel myself in

Re: [ck] Re: -mm merge plans for 2.6.23

I don't really understand the reasons for all those discussions. As long as you have a maintainer, why don't you just put swap prefetch into the kernel, marked experimental, default deactivated so anyone who just make[s] oldconfig (or defaultconfig) won't get it. If anyone finds a good solution

Re: [ck] Re: -mm merge plans for 2.6.23

On Thu, 26 Jul 2007 10:19:06 -0400 "Michael Chang" <[EMAIL PROTECTED]> wrote: > > All this would end up needing runtime configurability and tweakability and > > customisability. All standard fare for userspace stuff - much easier than > > patching the kernel. > > Maybe I'm missing something

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/26/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 25 Jul 2007 09:09:01 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote: > No, there's a third case which I find the most annoying. I have > multiple working sets, the sum of which won't fit into RAM. When I > finish one, the kernel had time

Re: [ck] Re: -mm merge plans for 2.6.23

On Thursday 26 July 2007, Jeff Garzik wrote: > Bartlomiej Zolnierkiewicz wrote: > > On Wednesday 25 July 2007, Ingo Molnar wrote: > >> you dont _have to_ cooperative with the maintainer, but it's certainly > >> useful to work with good maintainers, if your goal is to improve Linux. > >> Or if

Re: [ck] Re: -mm merge plans for 2.6.23

On Thursday 26 July 2007, Jeff Garzik wrote: Bartlomiej Zolnierkiewicz wrote: On Wednesday 25 July 2007, Ingo Molnar wrote: you dont _have to_ cooperative with the maintainer, but it's certainly useful to work with good maintainers, if your goal is to improve Linux. Or if for some

Re: [ck] Re: -mm merge plans for 2.6.23

I don't really understand the reasons for all those discussions. As long as you have a maintainer, why don't you just put swap prefetch into the kernel, marked experimental, default deactivated so anyone who just make[s] oldconfig (or defaultconfig) won't get it. If anyone finds a good solution

Re: [ck] Re: -mm merge plans for 2.6.23

On Thu, 26 Jul 2007, Jeff Garzik wrote: Dirk Schoebel wrote: as long as the maintainer follows the kernel development things can be left in, if the maintainer can't follow anymore they are taken out quite fast again. (This statement mostly counts for parts of the kernel where a choice is

Re: [ck] Re: -mm merge plans for 2.6.23

Dirk Schoebel wrote: as long as the maintainer follows the kernel development things can be left in, if the maintainer can't follow anymore they are taken out quite fast again. (This statement mostly counts for parts of the kernel where a choice is possible or the coding overhead of making

Re: [ck] Re: -mm merge plans for 2.6.23

...sorry for the reply to myself. As Gentoo user i'm happy about the freedom of choice in almost every aspect of the system. But with the kernel this freedom is taken away and i'm left with largely choices other people did. Sure, i can get the sources and patch and change the kernel myself in

Re: [ck] Re: -mm merge plans for 2.6.23

On Thu, 26 Jul 2007 10:19:06 -0400 Michael Chang [EMAIL PROTECTED] wrote: All this would end up needing runtime configurability and tweakability and customisability. All standard fare for userspace stuff - much easier than patching the kernel. Maybe I'm missing something here, but if

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/26/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 25 Jul 2007 09:09:01 -0700 Ray Lee [EMAIL PROTECTED] wrote: No, there's a third case which I find the most annoying. I have multiple working sets, the sum of which won't fit into RAM. When I finish one, the kernel had time to

Re: [ck] Re: -mm merge plans for 2.6.23

On Thu, 26 Jul 2007, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007, Jeff Garzik wrote: Dirk Schoebel wrote: as long as the maintainer follows the kernel development things can be left in, if the maintainer can't follow anymore they are taken out quite

Re: [ck] Re: -mm merge plans for 2.6.23

[EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007, Jeff Garzik wrote: Dirk Schoebel wrote: as long as the maintainer follows the kernel development things can be left in, if the maintainer can't follow anymore they are taken out quite fast again. (This statement mostly counts for parts of the

Re: [ck] Re: -mm merge plans for 2.6.23

Bartlomiej Zolnierkiewicz wrote: On Wednesday 25 July 2007, Ingo Molnar wrote: you dont _have to_ cooperative with the maintainer, but it's certainly useful to work with good maintainers, if your goal is to improve Linux. Or if for some reason communication is not working out fine then grow

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/26/07, Ray Lee <[EMAIL PROTECTED]> wrote: > Yeah, I know about inotify, but it doesn't scale. Yeah, the nonrecursive behaviour is a bugger. Also I found it helped to queue operations in userspace and execute periodically rather than trying to execute on every single notification. Worked

Re: [ck] Re: -mm merge plans for 2.6.23

Hi, Some general thoughts about submitter/maintainer responsibilities, not necessarily connected with the recents events (I hasn't been following them closely - some people don't have that much free time to burn at their hands ;)... On Wednesday 25 July 2007, Ingo Molnar wrote: > > * Satyam

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Matthew Hawkins <[EMAIL PROTECTED]> wrote: On 7/26/07, Ray Lee <[EMAIL PROTECTED]> wrote: > I'd just like updatedb to amortize its work better. If we had some way > to track all filesystem events, updatedb could keep a live and > accurate index on the filesystem. And this isn't just

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/26/07, Ray Lee <[EMAIL PROTECTED]> wrote: I'd just like updatedb to amortize its work better. If we had some way to track all filesystem events, updatedb could keep a live and accurate index on the filesystem. And this isn't just updatedb that wants that, beagle and tracker et al also want

Re: [ck] Re: -mm merge plans for 2.6.23

Question: Could those who have found this prefetch helps them alot say how many disks they have? In particular, is their swap on the same disk spindle as their root and user files? Answer - for me: On my system where updatedb is a big problem, I have one, slow, disk. On both desktop

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Paul Jackson <[EMAIL PROTECTED]> wrote: Question: Could those who have found this prefetch helps them alot say how many disks they have? In particular, is their swap on the same disk spindle as their root and user files? I have found that swap prefetch helped on all of the

Re: [ck] Re: -mm merge plans for 2.6.23

* Satyam Sharma <[EMAIL PROTECTED]> wrote: > > concentrate on making sure that both you and the maintainer > > understands the problem correctly, > > This itself may require some "convincing" to do. What if the > maintainer just doesn't recognize the problem? Note that the > development

Re: [ck] Re: -mm merge plans for 2.6.23

Hi Ingo, [ Going off-topic, nothing related to swap/prefetch/etc. Just getting a hang of how development goes on here ... ] On 7/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: * Rene Herman <[EMAIL PROTECTED]> wrote: > Nick Piggin is the person to convince it seems and if I've read things >

Re: [ck] Re: -mm merge plans for 2.6.23

* Rene Herman <[EMAIL PROTECTED]> wrote: > Nick Piggin is the person to convince it seems and if I've read things > right (I only stepped into this thing at the updatedb mention, so > maybe I haven't) his main question is _why_ the hell it helps > updatedb. [...] btw., i'd like to make this

Re: [ck] Re: -mm merge plans for 2.6.23

On 07/25/2007 12:53 PM, Jos Poortvliet wrote: On 7/25/07, *Rene Herman* <[EMAIL PROTECTED] > wrote: Also note I'm not against swap prefetch or anything. I don't use it and do not believe I have a pressing need for it, but do suspect it has potential to make quite a

Re: [ck] Re: -mm merge plans for 2.6.23

Jos Poortvliet wrote: Nick has been talking about 'fixing the updatedb thing' for years now, no patch yet. Wrong Nick, I think. First I heard about the updatedb problem was a few months ago with people saying updatedb was causing their system to swap (that is, swap prefetching helped after

Re: [ck] Re: -mm merge plans for 2.6.23

On Wed, 2007-25-07 at 08:47 +0200, Mike Galbraith wrote: > Heh. Here we have a VM developer expressing his interest in the problem > space, and you offer him a steaming jug of STFU because he doesn't say > what you want to hear. I wonder how many killfiles you just entered. > Agreed. (a bit

Re: [ck] Re: -mm merge plans for 2.6.23

On Wed, 2007-07-25 at 16:19 +1000, Matthew Hawkins wrote: > On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > > Not to say that neither fix some problems, but for such conceptually > > big changes, it should take a little more effort than a constructed test > > case and no consideration of the

Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Not to say that neither fix some problems, but for such conceptually big changes, it should take a little more effort than a constructed test case and no consideration of the alternatives to get it merged. Swap

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Not to say that neither fix some problems, but for such conceptually big changes, it should take a little more effort than a constructed test case and no consideration of the alternatives to get it merged. Swap Prefetch has existed since

Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: I'm not saying that we can't try to tackle that problem, but first of all you have a really nice narrow problem where updatedb seems to be causing the kernel to completely do the wrong thing. So we start on that.

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: I'm not saying that we can't try to tackle that problem, but first of all you have a really nice narrow problem where updatedb seems to be causing the kernel to completely do the wrong thing. So we start on that. updatedb isn't the only

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: I'm not saying that we can't try to tackle that problem, but first of all you have a really nice narrow problem where updatedb seems to be causing the kernel to completely do the wrong thing. So we start on that. updatedb isn't the only problem,

Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: I'm not saying that we can't try to tackle that problem, but first of all you have a really nice narrow problem where updatedb seems to be causing the kernel to completely do the wrong thing. So we start on that.

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: Not to say that neither fix some problems, but for such conceptually big changes, it should take a little more effort than a constructed test case and no consideration of the alternatives to get it merged. Swap Prefetch has existed since

Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: Not to say that neither fix some problems, but for such conceptually big changes, it should take a little more effort than a constructed test case and no consideration of the alternatives to get it merged. Swap Prefetch

Re: [ck] Re: -mm merge plans for 2.6.23

On Wed, 2007-07-25 at 16:19 +1000, Matthew Hawkins wrote: On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: Not to say that neither fix some problems, but for such conceptually big changes, it should take a little more effort than a constructed test case and no consideration of the

Re: [ck] Re: -mm merge plans for 2.6.23

On Wed, 2007-25-07 at 08:47 +0200, Mike Galbraith wrote: Heh. Here we have a VM developer expressing his interest in the problem space, and you offer him a steaming jug of STFU because he doesn't say what you want to hear. I wonder how many killfiles you just entered. Agreed. (a bit OT)

Re: [ck] Re: -mm merge plans for 2.6.23

Jos Poortvliet wrote: Nick has been talking about 'fixing the updatedb thing' for years now, no patch yet. Wrong Nick, I think. First I heard about the updatedb problem was a few months ago with people saying updatedb was causing their system to swap (that is, swap prefetching helped after

Re: [ck] Re: -mm merge plans for 2.6.23

* Rene Herman [EMAIL PROTECTED] wrote: Nick Piggin is the person to convince it seems and if I've read things right (I only stepped into this thing at the updatedb mention, so maybe I haven't) his main question is _why_ the hell it helps updatedb. [...] btw., i'd like to make this clear:

Re: [ck] Re: -mm merge plans for 2.6.23

On 07/25/2007 12:53 PM, Jos Poortvliet wrote: On 7/25/07, *Rene Herman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Also note I'm not against swap prefetch or anything. I don't use it and do not believe I have a pressing need for it, but do suspect it has potential to make quite a bit

Re: [ck] Re: -mm merge plans for 2.6.23

Hi Ingo, [ Going off-topic, nothing related to swap/prefetch/etc. Just getting a hang of how development goes on here ... ] On 7/25/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Rene Herman [EMAIL PROTECTED] wrote: Nick Piggin is the person to convince it seems and if I've read things right

Re: [ck] Re: -mm merge plans for 2.6.23

Question: Could those who have found this prefetch helps them alot say how many disks they have? In particular, is their swap on the same disk spindle as their root and user files? Answer - for me: On my system where updatedb is a big problem, I have one, slow, disk. On both desktop

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote: I'd just like updatedb to amortize its work better. If we had some way to track all filesystem events, updatedb could keep a live and accurate index on the filesystem. And this isn't just updatedb that wants that, beagle and tracker et al also want to

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Matthew Hawkins [EMAIL PROTECTED] wrote: On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote: I'd just like updatedb to amortize its work better. If we had some way to track all filesystem events, updatedb could keep a live and accurate index on the filesystem. And this isn't just

Re: [ck] Re: -mm merge plans for 2.6.23

Hi, Some general thoughts about submitter/maintainer responsibilities, not necessarily connected with the recents events (I hasn't been following them closely - some people don't have that much free time to burn at their hands ;)... On Wednesday 25 July 2007, Ingo Molnar wrote: * Satyam

Re: [ck] Re: -mm merge plans for 2.6.23

Bartlomiej Zolnierkiewicz wrote: On Wednesday 25 July 2007, Ingo Molnar wrote: you dont _have to_ cooperative with the maintainer, but it's certainly useful to work with good maintainers, if your goal is to improve Linux. Or if for some reason communication is not working out fine then grow

Re: [ck] Re: -mm merge plans for 2.6.23

* Satyam Sharma [EMAIL PROTECTED] wrote: concentrate on making sure that both you and the maintainer understands the problem correctly, This itself may require some convincing to do. What if the maintainer just doesn't recognize the problem? Note that the development model here is

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/25/07, Paul Jackson [EMAIL PROTECTED] wrote: Question: Could those who have found this prefetch helps them alot say how many disks they have? In particular, is their swap on the same disk spindle as their root and user files? I have found that swap prefetch helped on all of the

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote: Yeah, I know about inotify, but it doesn't scale. Yeah, the nonrecursive behaviour is a bugger. Also I found it helped to queue operations in userspace and execute periodically rather than trying to execute on every single notification. Worked well

Re: [ck] Re: -mm merge plans for 2.6.23

From: "Matthew Hawkins" <[EMAIL PROTECTED]> Date: Wed, 25 Jul 2007 11:26:57 +1000 > On 7/24/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > The other consideration here is, as Nick points out, are the problems which > > people see this patch solving for them solveable in other, better ways? > >

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/24/07, Andrew Morton <[EMAIL PROTECTED]> wrote: The other consideration here is, as Nick points out, are the problems which people see this patch solving for them solveable in other, better ways? IOW, is this patch fixing up preexisting deficiencies post-facto? So let me get this straight

Re: [ck] Re: -mm merge plans for 2.6.23

However, if we can improve basic page reclaim where it is obviously lacking, that is always preferable. eg: being a highly speculative operation, swap prefetch is not great for power efficiency -- but we still want laptop users to have a good experience as well, right? Sounds like something

Re: [ck] Re: -mm merge plans for 2.6.23

However, if we can improve basic page reclaim where it is obviously lacking, that is always preferable. eg: being a highly speculative operation, swap prefetch is not great for power efficiency -- but we still want laptop users to have a good experience as well, right? Sounds like something

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/24/07, Andrew Morton [EMAIL PROTECTED] wrote: The other consideration here is, as Nick points out, are the problems which people see this patch solving for them solveable in other, better ways? IOW, is this patch fixing up preexisting deficiencies post-facto? So let me get this straight -

Re: [ck] Re: -mm merge plans for 2.6.23

From: Matthew Hawkins [EMAIL PROTECTED] Date: Wed, 25 Jul 2007 11:26:57 +1000 On 7/24/07, Andrew Morton [EMAIL PROTECTED] wrote: The other consideration here is, as Nick points out, are the problems which people see this patch solving for them solveable in other, better ways? IOW, is this

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/12/07, Kacper Wysocki <[EMAIL PROTECTED]> wrote: performance, testing and impact. The big question is: why *don't* we merge it? Stranger thing to me is that this is like Déjà Vu. Many have asked this same question. When users were asked for their comment before many end users and some

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote: > We all know swap prefetch has been tested out the wazoo since Moses was a > little boy, is compile-time and runtime selectable, and gives an important > and

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an important and quantifiable

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/12/07, Kacper Wysocki [EMAIL PROTECTED] wrote: performance, testing and impact. The big question is: why *don't* we merge it? Stranger thing to me is that this is like Déjà Vu. Many have asked this same question. When users were asked for their comment before many end users and some

Re: [ck] Re: -mm merge plans for 2.6.23

On 11/07/07, Kevin Winchester <[EMAIL PROTECTED]> wrote: [snip] [1] Is there a graphical browser for linux that doesn't suck huge amounts of RAM? Dillo (http://www.dillo.org/) is really really tiny , a memory footprint somewhere in the hundreds of K area IIRC. links 2

Re: [ck] Re: -mm merge plans for 2.6.23

On Tue, 10 Jul 2007 18:14:19 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> > wrote: > > > We all know swap prefetch has been tested out the wazoo since Moses was a > > little boy, is compile-time and runtime selectable,

Re: [ck] Re: -mm merge plans for 2.6.23

Ray Lee wrote: As an honest question, what's it going to take here? If I were to write something that watched the task stats at process exit (cool feature, that), and recorded the IO wait time or some such, and showed it was lower with a kernel with the prefetch, would *that* get us some

Re: [ck] Re: -mm merge plans for 2.6.23

Ray Lee wrote: On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote: >> OK that's a good data point. It would be really good to be able to >> do an analysis on your overnight IO patterns and the corresponding >> memory reclaim behaviour and see why things are getting evicted. > > Eviction can

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Matthew Hawkins wrote: > On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > Anyhow with swap prefetch, applications that may have been sitting > there idle for a while become responsive in the single-digit seconds > rather than double-digit

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote: >> OK that's a good data point. It would be really good to be able to >> do an analysis on your overnight IO patterns and the corresponding >> memory reclaim behaviour and see why things are getting evicted. > > Eviction can happen for multiple

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote: OK that's a good data point. It would be really good to be able to do an analysis on your overnight IO patterns and the corresponding memory reclaim behaviour and see why things are getting evicted. Eviction can happen for multiple reasons,

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote: Matthew Hawkins wrote: On 7/11/07, Andrew Morton [EMAIL PROTECTED] wrote: Anyhow with swap prefetch, applications that may have been sitting there idle for a while become responsive in the single-digit seconds rather than double-digit or

Re: [ck] Re: -mm merge plans for 2.6.23

Ray Lee wrote: On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote: OK that's a good data point. It would be really good to be able to do an analysis on your overnight IO patterns and the corresponding memory reclaim behaviour and see why things are getting evicted. Eviction can happen for

Re: [ck] Re: -mm merge plans for 2.6.23

Ray Lee wrote: As an honest question, what's it going to take here? If I were to write something that watched the task stats at process exit (cool feature, that), and recorded the IO wait time or some such, and showed it was lower with a kernel with the prefetch, would *that* get us some

Re: [ck] Re: -mm merge plans for 2.6.23

On Tue, 10 Jul 2007 18:14:19 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an

Re: [ck] Re: -mm merge plans for 2.6.23

On 11/07/07, Kevin Winchester [EMAIL PROTECTED] wrote: [snip] [1] Is there a graphical browser for linux that doesn't suck huge amounts of RAM? Dillo (http://www.dillo.org/) is really really tiny , a memory footprint somewhere in the hundreds of K area IIRC. links 2

Re: [ck] Re: -mm merge plans for 2.6.23

Ray Lee wrote: On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Matthew Hawkins wrote: > On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > Anyhow with swap prefetch, applications that may have been sitting > there idle for a while become responsive in the single-digit seconds > rather

Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: Anyhow with swap prefetch, applications that may have been sitting there idle for a while become responsive in the single-digit seconds rather than double-digit or worse. The same goes for a morning wakeup (ie after

Re: [ck] Re: -mm merge plans for 2.6.23

On Tue, 10 Jul 2007, Andrew Morton wrote: On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an important and quantifiable

Re: [ck] Re: -mm merge plans for 2.6.23

Ira Snyder <[EMAIL PROTECTED]> writes: >> Always interested. Please provide us more details on your usage and >> testing of that code. Amount of memory, workload, observed results, >> etc? >> > > I often leave long compiles running overnight (I'm a gentoo user). I > always have the desktop

Re: [ck] Re: -mm merge plans for 2.6.23

On Tue, 10 Jul 2007 18:14:19 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> > wrote: > > > We all know swap prefetch has been tested out the wazoo since Moses was a > > little boy, is compile-time and runtime selectable,

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote: Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? My usual

Re: [ck] Re: -mm merge plans for 2.6.23

On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote: > We all know swap prefetch has been tested out the wazoo since Moses was a > little boy, is compile-time and runtime selectable, and gives an important > and quantifiable performance increase to desktop systems.

Re: [ck] Re: -mm merge plans for 2.6.23

On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an important and quantifiable performance increase to desktop systems. Always

Re: [ck] Re: -mm merge plans for 2.6.23

On 7/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? My usual workstation

Re: [ck] Re: -mm merge plans for 2.6.23

On Tue, 10 Jul 2007 18:14:19 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an

Re: [ck] Re: -mm merge plans for 2.6.23

Ira Snyder [EMAIL PROTECTED] writes: Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? I often leave long compiles running overnight (I'm a gentoo user). I always have the desktop running, with

Re: [ck] Re: -mm merge plans for 2.6.23

On Tue, 10 Jul 2007, Andrew Morton wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an important and quantifiable

Re: [ck] Re: -mm merge plans for 2.6.23

Matthew Hawkins wrote: On 7/11/07, Andrew Morton [EMAIL PROTECTED] wrote: Anyhow with swap prefetch, applications that may have been sitting there idle for a while become responsive in the single-digit seconds rather than double-digit or worse. The same goes for a morning wakeup (ie after

Re: [ck] Re: -mm merge plans for 2.6.23

Ray Lee wrote: On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote: Matthew Hawkins wrote: On 7/11/07, Andrew Morton [EMAIL PROTECTED] wrote: Anyhow with swap prefetch, applications that may have been sitting there idle for a while become responsive in the single-digit seconds rather than