On Friday 27 July 2007 19:29:19 Andi Kleen wrote:
> > Any faults in that reasoning?
>
> GNU sort uses a merge sort with temporary files on disk. Not sure
> how much it keeps in memory during that, but it's probably less
> than 150MB. At some point the dirty limit should kick in and write back the
On Wed, Jul 25, 2007 at 11:50:37PM -0700, Andrew Morton wrote:
> On Wed, 25 Jul 2007 23:33:24 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote:
>
> > > So. We can
> > >
> > > a) provide a way for userspace to reload pagecache and
> > >
> > > b) merge maps2 (once it's finished) (pokes mpm)
> > >
> > >
On Wed, Jul 25, 2007 at 09:57:17PM -0700, Andrew Morton wrote:
> So. We can
>
> a) provide a way for userspace to reload pagecache and
>
> b) merge maps2 (once it's finished) (pokes mpm)
Consider me poked, despite not being cc:ed.
--
Mathematics is the supreme nostalgia of our time.
-
To
On 2007.07.28 01:29:19 +0200, Andi Kleen wrote:
> > Any faults in that reasoning?
>
> GNU sort uses a merge sort with temporary files on disk. Not sure
> how much it keeps in memory during that, but it's probably less
> than 150MB. At some point the dirty limit should kick in and write back the
> Any faults in that reasoning?
GNU sort uses a merge sort with temporary files on disk. Not sure
how much it keeps in memory during that, but it's probably less
than 150MB. At some point the dirty limit should kick in and write back the
data of the temporary files; so it's not quite the same as
On 2007.07.27 20:16:32 +0200, Rene Herman wrote:
> On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
>
>> Updatedb or another process that uses the FS heavily runs on a users
>> 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
>> pressure that causes other applications to be
On Friday 27 July 2007 18:08:44 Mike Galbraith wrote:
> On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote:
> > On Friday 27 July 2007 06:25:18 Mike Galbraith wrote:
> > > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
> > > > So hrm. Are we sure that updatedb is the problem?
On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote:
> On Friday 27 July 2007 06:25:18 Mike Galbraith wrote:
> > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
> > > So hrm. Are we sure that updatedb is the problem? There are quite a few
> > > heavyweight things which happen in
On Friday 27 July 2007 14:16:32 Rene Herman wrote:
> On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
> > Updatedb or another process that uses the FS heavily runs on a users
> > 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
> > pressure that causes other applications to be
On Fri, 27 Jul 2007, Rene Herman wrote:
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to disk.
Al Viro wrote:
> BTW, I really wonder how much pain could be avoided if updatedb recorded
> mtime of directories and checked it.
Someone mentioned a variant of slocate above that they called mlocate,
and that Red Hat ships, that seems to do this (if I understand you and
what mlocate does
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to disk. In the
morning the user has to wait for the
On Friday 27 July 2007 06:25:18 Mike Galbraith wrote:
> On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
> > On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton
<[EMAIL PROTECTED]> wrote:
> > > More sophisticated testing is needed - there's something in
> > > ext3-tools which will mmap, page
On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
> On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > More sophisticated testing is needed - there's something in
> > ext3-tools which will mmap, page in and hold a file for you.
>
> So much for that theory.
On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> More sophisticated testing is needed - there's something in
> ext3-tools which will mmap, page in and hold a file for you.
So much for that theory. afaict mmapped, active pagecache is immune to
updatedb activity. It
On Fri, 2007-07-27 at 01:47 -0700, Andrew Morton wrote:
> Anyway, blockdev pagecache is a problem, I expect. It's worth playing with
> that patch.
(may tinker a bit, but i'm way rusty. ain't had the urge to mutilate
anything down there in quite a while... works just fine for me these
days)
>
On Fri, 27 Jul 2007 09:54:41 +0100 Al Viro <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 27, 2007 at 01:47:49AM -0700, Andrew Morton wrote:
> > What I think is killing us here is the blockdev pagecache: the pagecache
> > which backs those directory entries and inodes. These pages get read
> >
On Fri, Jul 27, 2007 at 01:47:49AM -0700, Andrew Morton wrote:
> What I think is killing us here is the blockdev pagecache: the pagecache
> which backs those directory entries and inodes. These pages get read
> multiple times because they hold multiple directory entries and multiple
> inodes.
On Fri, 27 Jul 2007 09:23:41 +0200 Mike Galbraith <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-07-27 at 07:13 +0200, Mike Galbraith wrote:
> > On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote:
> > > > drops caches prior to both updatedb runs.
> > >
> > > I think that was the wrong thing to
On Fri, 2007-07-27 at 07:13 +0200, Mike Galbraith wrote:
> On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote:
> > > drops caches prior to both updatedb runs.
> >
> > I think that was the wrong thing to do. That will leave gobs of free
> > memory for updatedb to populate with dentries and
On Fri, 2007-07-27 at 07:13 +0200, Mike Galbraith wrote:
On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote:
drops caches prior to both updatedb runs.
I think that was the wrong thing to do. That will leave gobs of free
memory for updatedb to populate with dentries and inodes.
On Fri, Jul 27, 2007 at 01:47:49AM -0700, Andrew Morton wrote:
What I think is killing us here is the blockdev pagecache: the pagecache
which backs those directory entries and inodes. These pages get read
multiple times because they hold multiple directory entries and multiple
inodes. These
On Fri, 27 Jul 2007 09:23:41 +0200 Mike Galbraith [EMAIL PROTECTED] wrote:
On Fri, 2007-07-27 at 07:13 +0200, Mike Galbraith wrote:
On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote:
drops caches prior to both updatedb runs.
I think that was the wrong thing to do. That will
On Fri, 2007-07-27 at 01:47 -0700, Andrew Morton wrote:
Anyway, blockdev pagecache is a problem, I expect. It's worth playing with
that patch.
(may tinker a bit, but i'm way rusty. ain't had the urge to mutilate
anything down there in quite a while... works just fine for me these
days)
On Fri, 27 Jul 2007 09:54:41 +0100 Al Viro [EMAIL PROTECTED] wrote:
On Fri, Jul 27, 2007 at 01:47:49AM -0700, Andrew Morton wrote:
What I think is killing us here is the blockdev pagecache: the pagecache
which backs those directory entries and inodes. These pages get read
multiple times
On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
More sophisticated testing is needed - there's something in
ext3-tools which will mmap, page in and hold a file for you.
So much for that theory. afaict mmapped, active pagecache is immune to
updatedb activity. It just
On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
More sophisticated testing is needed - there's something in
ext3-tools which will mmap, page in and hold a file for you.
So much for that theory. afaict
On Friday 27 July 2007 06:25:18 Mike Galbraith wrote:
On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton
[EMAIL PROTECTED] wrote:
More sophisticated testing is needed - there's something in
ext3-tools which will mmap, page in and hold
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to disk. In the
morning the user has to wait for the
On Fri, 27 Jul 2007, Rene Herman wrote:
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to disk.
Al Viro wrote:
BTW, I really wonder how much pain could be avoided if updatedb recorded
mtime of directories and checked it.
Someone mentioned a variant of slocate above that they called mlocate,
and that Red Hat ships, that seems to do this (if I understand you and
what mlocate does
On Friday 27 July 2007 14:16:32 Rene Herman wrote:
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped
On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote:
On Friday 27 July 2007 06:25:18 Mike Galbraith wrote:
On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
So hrm. Are we sure that updatedb is the problem? There are quite a few
heavyweight things which happen in the wee
On Friday 27 July 2007 18:08:44 Mike Galbraith wrote:
On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote:
On Friday 27 July 2007 06:25:18 Mike Galbraith wrote:
On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote:
So hrm. Are we sure that updatedb is the problem? There are
On 2007.07.27 20:16:32 +0200, Rene Herman wrote:
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to
Any faults in that reasoning?
GNU sort uses a merge sort with temporary files on disk. Not sure
how much it keeps in memory during that, but it's probably less
than 150MB. At some point the dirty limit should kick in and write back the
data of the temporary files; so it's not quite the same as
On 2007.07.28 01:29:19 +0200, Andi Kleen wrote:
Any faults in that reasoning?
GNU sort uses a merge sort with temporary files on disk. Not sure
how much it keeps in memory during that, but it's probably less
than 150MB. At some point the dirty limit should kick in and write back the
data
On Wed, Jul 25, 2007 at 09:57:17PM -0700, Andrew Morton wrote:
So. We can
a) provide a way for userspace to reload pagecache and
b) merge maps2 (once it's finished) (pokes mpm)
Consider me poked, despite not being cc:ed.
--
Mathematics is the supreme nostalgia of our time.
-
To
On Wed, Jul 25, 2007 at 11:50:37PM -0700, Andrew Morton wrote:
On Wed, 25 Jul 2007 23:33:24 -0700 Ray Lee [EMAIL PROTECTED] wrote:
So. We can
a) provide a way for userspace to reload pagecache and
b) merge maps2 (once it's finished) (pokes mpm)
and we're done?
Eh,
On Friday 27 July 2007 19:29:19 Andi Kleen wrote:
Any faults in that reasoning?
GNU sort uses a merge sort with temporary files on disk. Not sure
how much it keeps in memory during that, but it's probably less
than 150MB. At some point the dirty limit should kick in and write back the
data
Andrew Morton wrote:
[...]
And userspace can do a much better implementation of this
how-to-handle-large-load-shifts problem, because it is really quite
complex. The system needs to be monitored to determine what is the usual
[...]
All this would end up needing runtime configurability and
On 07/27/2007 10:28 PM, Daniel Hazelton wrote:
Check the attitude at the door then re-read what I actually said:
Attitude? You wanted attitude dear boy?
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing
On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote:
> On Thu, 26 Jul 2007 14:46:58 +0200 Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-07-26 at 03:09 -0700, Andrew Morton wrote:
> >
> > > Setting it to zero will maximise the preservation of the vfs caches. You
> > > wanted
Al Boldi wrote:
>
> Thanks for asking. I'm rather surprised why nobody's noticing any of this
> slowdown. To be fair, it's not really a regression, on the contrary, 2.4 is
> lot worse wrt swapin and swapout, and Rik van Riel even considers a 50%
> swapin slowdown wrt swapout something like
On 7/26/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> wrong, it's active on three of my boxes already :) But then again, i
> never had these hangover problems. (not really expected with gigs of RAM
> anyway)
[...]
> --- /etc/cron.daily/mlocate.cron.orig
[...]
mlocate by design doesn't thrash the
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
> >
[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
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
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
...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
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
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
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
On Thu, 26 Jul 2007 14:46:58 +0200 Mike Galbraith <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-07-26 at 03:09 -0700, Andrew Morton wrote:
>
> > Setting it to zero will maximise the preservation of the vfs caches. You
> > wanted 1 there.
> >
> >
>
> drops caches prior to both updatedb runs.
On Thu, Jul 26, 2007 at 02:23:30PM +0200, Andi Kleen wrote:
> That would just save reading the directories. Not sure
> it helps that much. Much better would be actually if it didn't stat the
> individual files (and force their dentries/inodes in). I bet it does that to
> find out if they are
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
On Thu, 2007-07-26 at 03:09 -0700, Andrew Morton wrote:
> Setting it to zero will maximise the preservation of the vfs caches. You
> wanted 1 there.
>
>
drops caches prior to both updatedb runs.
[EMAIL PROTECTED]: df -i
FilesystemInodes IUsed IFree IUse% Mounted on
> BTW, I really wonder how much pain could be avoided if updatedb recorded
> mtime of directories and checked it. I.e. instead of just doing blind
> find(1), walk the stored directory tree comparing timestamps with those
> in filesystem. If directory mtime has not changed, don't bother rereading
On Thu, 26 Jul 2007 12:27:30 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > > > ( we _do_ want to baloon the dentry cache otherwise - for things like
> > > > > "find" - having a fast VFS is important. But known-use-once things
> > > > >
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > ( we _do_ want to baloon the dentry cache otherwise - for things like
> > > > "find" - having a fast VFS is important. But known-use-once things
> > > > like the daily updatedb job can clearly be annotated properly. )
> > >
> > > Mutter.
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
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Setting it to zero will maximise the preservation of the vfs caches.
> You wanted 1 there.
ok, updated patch below :-)
>
wrong, it's active on three of my boxes already :) But then again, i
never had these hangover problems. (not really
On Thu, Jul 26, 2007 at 11:40:24AM +0200, Ingo Molnar wrote:
> below is an updatedb hack that sets vfs_cache_pressure down to 0 during
> an updatedb run. Could someone who is affected by the 'morning after'
> problem give it a try? If this works then we can think about any other
> measures ...
On Thu, 26 Jul 2007 11:40:24 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 26 Jul 2007 11:20:25 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > Once we give the kernel the knowledge that the dentry wont be used again
> > > by
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Jul 2007 11:20:25 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > Once we give the kernel the knowledge that the dentry wont be used again
> > by this app, the kernel can do a lot more intelligent decision and not
> > baloon the
On Thu, 26 Jul 2007 11:20:25 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Once we give the kernel the knowledge that the dentry wont be used again
> by this app, the kernel can do a lot more intelligent decision and not
> baloon the dentry cache.
>
> ( we _do_ want to baloon the dentry cache
* Frank Kingswood <[EMAIL PROTECTED]> wrote:
> > Disadvantage would be that the userland would need to be patched,
> > but I guess it's better than adding very dubious heuristics to the
> > kernel.
>
> Are you going to change every single large memory application in the
> world? As I wrote
Andi Kleen wrote:
One simple way to fix this would be to implement a fadvise() flag
that puts the dentry/inode on a "soon to be expired" list if there
are no other references. Then if a dentry allocation needs more
memory try to reuse dentries from that list (or better queue) first. Any other
Ray Lee wrote:
Another is a more philosophical hangup -- running a process that polls
periodically to improve system performance seems backward.
You mean like the kprefetchd of swap prefetch? ;)
Okay, so
that's my problem to get over, not yours.
If it was a problem you could add some
On 7/25/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 25 Jul 2007 23:33:24 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote:
> If you think that adding that API and maintaining it is
> simpler/better than including a variation on the above hueristic I
> offered, then yeah, I guess we are. It'll
On Wed, 25 Jul 2007 23:33:24 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote:
> > So. We can
> >
> > a) provide a way for userspace to reload pagecache and
> >
> > b) merge maps2 (once it's finished) (pokes mpm)
> >
> > and we're done?
>
> Eh, dunno. Maybe?
>
> We're assuming we come up with an API
On 7/25/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
Andrew Morton wrote:
On Thu, 26 Jul 2007 15:53:37 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Not that I want to say anything about swap prefetch getting merged: my
inbox is already full of enough "helpful suggestions" about that,
give them the kernel interfaces, they can do it themselves
On Thu, 26 Jul 2007 15:53:37 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Not that I want to say anything about swap prefetch getting merged: my
> inbox is already full of enough "helpful suggestions" about that,
give them the kernel interfaces, they can do it themselves ;)
> so I'll
> just
On 7/25/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007 23:33:24 -0700 Ray Lee [EMAIL PROTECTED] wrote:
If you think that adding that API and maintaining it is
simpler/better than including a variation on the above hueristic I
offered, then yeah, I guess we are. It'll all have
Andi Kleen wrote:
One simple way to fix this would be to implement a fadvise() flag
that puts the dentry/inode on a soon to be expired list if there
are no other references. Then if a dentry allocation needs more
memory try to reuse dentries from that list (or better queue) first. Any other
On Thu, 26 Jul 2007 11:40:24 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 26 Jul 2007 11:20:25 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
Once we give the kernel the knowledge that the dentry wont be used again
by this app, the
On Thu, 26 Jul 2007 12:27:30 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
( we _do_ want to baloon the dentry cache otherwise - for things like
find - having a fast VFS is important. But known-use-once things
like the daily updatedb
* Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 26 Jul 2007 11:20:25 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
Once we give the kernel the knowledge that the dentry wont be used again
by this app, the kernel can do a lot more intelligent decision and not
baloon the dentry cache.
* Frank Kingswood [EMAIL PROTECTED] wrote:
Disadvantage would be that the userland would need to be patched,
but I guess it's better than adding very dubious heuristics to the
kernel.
Are you going to change every single large memory application in the
world? As I wrote before, it
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
* Andrew Morton [EMAIL PROTECTED] wrote:
Setting it to zero will maximise the preservation of the vfs caches.
You wanted 1 there.
ok, updated patch below :-)
bets that nobody will test this
wrong, it's active on three of my boxes already :) But then again, i
never had these hangover
On Thu, Jul 26, 2007 at 11:40:24AM +0200, Ingo Molnar wrote:
below is an updatedb hack that sets vfs_cache_pressure down to 0 during
an updatedb run. Could someone who is affected by the 'morning after'
problem give it a try? If this works then we can think about any other
measures ...
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
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
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
...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
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
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
On Thu, 26 Jul 2007 11:20:25 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
Once we give the kernel the knowledge that the dentry wont be used again
by this app, the kernel can do a lot more intelligent decision and not
baloon the dentry cache.
( we _do_ want to baloon the dentry cache
Ray Lee wrote:
Another is a more philosophical hangup -- running a process that polls
periodically to improve system performance seems backward.
You mean like the kprefetchd of swap prefetch? ;)
Okay, so
that's my problem to get over, not yours.
If it was a problem you could add some
On 7/25/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
On 7/26/07, Ingo Molnar [EMAIL PROTECTED] wrote:
wrong, it's active on three of my boxes already :) But then again, i
never had these hangover problems. (not really expected with gigs of RAM
anyway)
[...]
--- /etc/cron.daily/mlocate.cron.orig
[...]
mlocate by design doesn't thrash the cache
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
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
On Thu, 26 Jul 2007 14:46:58 +0200 Mike Galbraith [EMAIL PROTECTED] wrote:
On Thu, 2007-07-26 at 03:09 -0700, Andrew Morton wrote:
Setting it to zero will maximise the preservation of the vfs caches. You
wanted 1 there.
bets that nobody will test this
drops caches prior to
On Wed, 25 Jul 2007 23:33:24 -0700 Ray Lee [EMAIL PROTECTED] wrote:
So. We can
a) provide a way for userspace to reload pagecache and
b) merge maps2 (once it's finished) (pokes mpm)
and we're done?
Eh, dunno. Maybe?
We're assuming we come up with an API for userspace to get
On Thu, 26 Jul 2007 15:53:37 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Not that I want to say anything about swap prefetch getting merged: my
inbox is already full of enough helpful suggestions about that,
give them the kernel interfaces, they can do it themselves ;)
so I'll
just be happy
Al Boldi wrote:
Thanks for asking. I'm rather surprised why nobody's noticing any of this
slowdown. To be fair, it's not really a regression, on the contrary, 2.4 is
lot worse wrt swapin and swapout, and Rik van Riel even considers a 50%
swapin slowdown wrt swapout something like better
[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
101 - 200 of 707 matches
Mail list logo
