On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
> Eric St-Laurent wrote:
> > I test this on my main system, so patches with basic testing and
> > reasonable stability are preferred. I just want to avoid data corruption
> > bugs. FYI, I used to run the -rt tree most of the time.
>
> OK here
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
Eric St-Laurent wrote:
I test this on my main system, so patches with basic testing and
reasonable stability are preferred. I just want to avoid data corruption
bugs. FYI, I used to run the -rt tree most of the time.
OK here is one
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
A new list could be a possibility. One problem with adding lists is just
trying to work out how to balance scanning rates between them, another
problem is CPU overhead of moving pages from one to another...
Disk
Nick Piggin wrote:
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the
Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the list
without disturbing active data too much.
I think there is a missing piece
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
>
> A new list could be a possibility. One problem with adding lists is just
> trying to work out how to balance scanning rates between them, another
> problem is CPU overhead of moving pages from one to another...
Disk sizes seem to
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the list
without
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
> What *I* think is supposed to happen is that newly read in pages get
> put on the inactive list, and unless they get accessed againbefore
> being reclaimed, they are allowed to fall off the end of the list
> without disturbing active data
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the list
without disturbing active data too
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the list
without
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
A new list could be a possibility. One problem with adding lists is just
trying to work out how to balance scanning rates between them, another
problem is CPU overhead of moving pages from one to another...
Disk sizes seem to increase
Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the list
without disturbing active data too much.
I think there is a missing piece
Nick Piggin wrote:
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
A new list could be a possibility. One problem with adding lists is just
trying to work out how to balance scanning rates between them, another
problem is CPU overhead of moving pages from one to another...
Disk
Eric St-Laurent wrote:
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
I don't like this kind of conditional information going from something
like readahead into page reclaim. Unless it is for readahead _specific_
data such as "I got these all wrong, so you can reclaim them" (which
this
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
> I don't like this kind of conditional information going from something
> like readahead into page reclaim. Unless it is for readahead _specific_
> data such as "I got these all wrong, so you can reclaim them" (which
> this isn't).
>
> But I
On Jul 23, 2007 18:17 -0700, Andrew Morton wrote:
> hm, yes, there is a risk that the code was accidentally correct. Or the
> code has only ever dealt with power-of-2 inputs, in which case it happens
> to work either way.
>
> David(s) and ext4-people: could we please have a close review of
On Jul 23, 2007 18:17 -0700, Andrew Morton wrote:
hm, yes, there is a risk that the code was accidentally correct. Or the
code has only ever dealt with power-of-2 inputs, in which case it happens
to work either way.
David(s) and ext4-people: could we please have a close review of these
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
I don't like this kind of conditional information going from something
like readahead into page reclaim. Unless it is for readahead _specific_
data such as I got these all wrong, so you can reclaim them (which
this isn't).
But I don't
Eric St-Laurent wrote:
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
I don't like this kind of conditional information going from something
like readahead into page reclaim. Unless it is for readahead _specific_
data such as I got these all wrong, so you can reclaim them (which
this
Fengguang Wu wrote:
On Mon, Jul 23, 2007 at 12:40:09PM -0700, Andrew Morton wrote:
This is all fun stuff, but how do we find out that changes like this are
good ones, apart from shipping it and seeing who gets hurt 12 months later?
One thing I can imagine now is that the first pages may
On Tue, 24 Jul 2007 08:47:28 +0800
Fengguang Wu <[EMAIL PROTECTED]> wrote:
> Subject: convert ill defined log2() to ilog2()
>
> It's *wrong* to have
> #define log2(n) ffz(~(n))
> It should be *reversed*:
> #define log2(n) flz(~(n))
> or
>
On Mon, Jul 23, 2007 at 12:40:09PM -0700, Andrew Morton wrote:
> On Mon, 23 Jul 2007 22:24:57 +0800
> Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jul 23, 2007 at 07:00:59PM +1000, Nick Piggin wrote:
> > > Rusty Russell wrote:
> > > >On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
On Mon, 23 Jul 2007 22:24:57 +0800
Fengguang Wu <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 23, 2007 at 07:00:59PM +1000, Nick Piggin wrote:
> > Rusty Russell wrote:
> > >On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
> >
> > >>So I opt for it being made tunable, safe, and turned off by
On Mon, Jul 23, 2007 at 07:00:59PM +1000, Nick Piggin wrote:
> Rusty Russell wrote:
> >On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
>
> >>So I opt for it being made tunable, safe, and turned off by default.
>
> I hate tunables :) Unless we have workload A that gets a reasonable
>
Rusty Russell wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
So I opt for it being made tunable, safe, and turned off by default.
I hate tunables :) Unless we have workload A that gets a reasonable
benefit from something and workload B that gets a significant regression,
and
Rusty Russell wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
So I opt for it being made tunable, safe, and turned off by default.
I hate tunables :) Unless we have workload A that gets a reasonable
benefit from something and workload B that gets a significant regression,
and
On Mon, Jul 23, 2007 at 07:00:59PM +1000, Nick Piggin wrote:
Rusty Russell wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
So I opt for it being made tunable, safe, and turned off by default.
I hate tunables :) Unless we have workload A that gets a reasonable
benefit from
On Mon, 23 Jul 2007 22:24:57 +0800
Fengguang Wu [EMAIL PROTECTED] wrote:
On Mon, Jul 23, 2007 at 07:00:59PM +1000, Nick Piggin wrote:
Rusty Russell wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
So I opt for it being made tunable, safe, and turned off by default.
I
On Mon, Jul 23, 2007 at 12:40:09PM -0700, Andrew Morton wrote:
On Mon, 23 Jul 2007 22:24:57 +0800
Fengguang Wu [EMAIL PROTECTED] wrote:
On Mon, Jul 23, 2007 at 07:00:59PM +1000, Nick Piggin wrote:
Rusty Russell wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
So I
On Tue, 24 Jul 2007 08:47:28 +0800
Fengguang Wu [EMAIL PROTECTED] wrote:
Subject: convert ill defined log2() to ilog2()
It's *wrong* to have
#define log2(n) ffz(~(n))
It should be *reversed*:
#define log2(n) flz(~(n))
or
Fengguang Wu wrote:
On Mon, Jul 23, 2007 at 12:40:09PM -0700, Andrew Morton wrote:
This is all fun stuff, but how do we find out that changes like this are
good ones, apart from shipping it and seeing who gets hurt 12 months later?
One thing I can imagine now is that the first pages may
Fengguang Wu wrote:
> On Sun, Jul 22, 2007 at 10:24:37AM +0200, Peter Zijlstra wrote:
> > On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
> > > - It will avoid large-file-reads-thrashing-my-desktop problem,
> > > so most desktop users should like it. But sure there will be counter
> > >
On Sun, 2007-07-22 at 18:33 +1000, Rusty Russell wrote:
> On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
> > - It will avoid large-file-reads-thrashing-my-desktop problem,
> > so most desktop users should like it. But sure there will be counter
> > cases when a user want to keep the
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
> - It will avoid large-file-reads-thrashing-my-desktop problem,
> so most desktop users should like it. But sure there will be counter
> cases when a user want to keep the data cached.
> - File servers may hurt from it. Imagine a mp3/png
On Sun, Jul 22, 2007 at 10:24:37AM +0200, Peter Zijlstra wrote:
> On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
>
> > - It will avoid large-file-reads-thrashing-my-desktop problem,
> > so most desktop users should like it. But sure there will be counter
> > cases when a user want to
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
> - It will avoid large-file-reads-thrashing-my-desktop problem,
> so most desktop users should like it. But sure there will be counter
> cases when a user want to keep the data cached.
> - File servers may hurt from it. Imagine a mp3/png
On Sat, Jul 21, 2007 at 10:44:28PM -0400, Dave Jones wrote:
> On Sun, Jul 22, 2007 at 10:39:23AM +0800, Fengguang Wu wrote:
>
> > It makes sense to raise it beyond 128K. 1M default readahead
> > absolutely makes sense for sequential workloads. For the desktop,
> > this increases boot speed
On Sat, Jul 21, 2007 at 10:44:28PM -0400, Dave Jones wrote:
On Sun, Jul 22, 2007 at 10:39:23AM +0800, Fengguang Wu wrote:
It makes sense to raise it beyond 128K. 1M default readahead
absolutely makes sense for sequential workloads. For the desktop,
this increases boot speed and
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
- It will avoid large-file-reads-thrashing-my-desktop problem,
so most desktop users should like it. But sure there will be counter
cases when a user want to keep the data cached.
- File servers may hurt from it. Imagine a mp3/png
On Sun, Jul 22, 2007 at 10:24:37AM +0200, Peter Zijlstra wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
- It will avoid large-file-reads-thrashing-my-desktop problem,
so most desktop users should like it. But sure there will be counter
cases when a user want to keep the
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
- It will avoid large-file-reads-thrashing-my-desktop problem,
so most desktop users should like it. But sure there will be counter
cases when a user want to keep the data cached.
- File servers may hurt from it. Imagine a mp3/png file
On Sun, 2007-07-22 at 18:33 +1000, Rusty Russell wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
- It will avoid large-file-reads-thrashing-my-desktop problem,
so most desktop users should like it. But sure there will be counter
cases when a user want to keep the data
Fengguang Wu wrote:
On Sun, Jul 22, 2007 at 10:24:37AM +0200, Peter Zijlstra wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
- It will avoid large-file-reads-thrashing-my-desktop problem,
so most desktop users should like it. But sure there will be counter
cases when
On Sun, Jul 22, 2007 at 10:39:23AM +0800, Fengguang Wu wrote:
> It makes sense to raise it beyond 128K. 1M default readahead
> absolutely makes sense for sequential workloads. For the desktop,
> this increases boot speed and readahead misses, both due to more
> aggressive mmap read-around.
On Sat, Jul 21, 2007 at 11:00:05PM +0200, Peter Zijlstra wrote:
> The various readahead bits I have lying about.
>
> Wu, would you agree with asking Andrew to stick these behind your latest
> readahead series?
They are generally good feature to have. Thank you!
- default readahead size
It
The various readahead bits I have lying about.
Wu, would you agree with asking Andrew to stick these behind your latest
readahead series?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
The various readahead bits I have lying about.
Wu, would you agree with asking Andrew to stick these behind your latest
readahead series?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sat, Jul 21, 2007 at 11:00:05PM +0200, Peter Zijlstra wrote:
The various readahead bits I have lying about.
Wu, would you agree with asking Andrew to stick these behind your latest
readahead series?
They are generally good feature to have. Thank you!
- default readahead size
It makes
On Sun, Jul 22, 2007 at 10:39:23AM +0800, Fengguang Wu wrote:
It makes sense to raise it beyond 128K. 1M default readahead
absolutely makes sense for sequential workloads. For the desktop,
this increases boot speed and readahead misses, both due to more
aggressive mmap read-around.
50 matches
Mail list logo
