Re: 2.6.4-rc1-mm1

[Andrew Morton]

Nick Piggin <piggin@xxxxxxxxxxxxxxx> wrote:
>
> I had one addition which is to use a "refill_counter" for inactive
>  list scanning as well so the scanning is batched up now that we don't
>  round up the amount to be done. No observed benefits, but I imagine
>  it would lower the acquisition frequency of the lru locks in some
>  cases?

Might do, yes.

Also I think you did some work on the inactive-vs-active list balancing?  I
have spent precisely zero time looking at or working on that since
2.5.nothing and it's entirely possible that it is doing something
inappropriate.

>  Should I start testing again, or are you still doing more to vmscan?

Now would be a good time.  The only thing I'm likely to look at in the next
several days is accounting for the slab fragmentation.  My current thinking
is to solve that by making slab account for the number of objects and the
number of pages, and to use that in shrink_dcache_memory(), so it doesn't
touch vmscan.c at all.

>  Nikita's dont-rotate-active-list.patch looks to be the only major
>  casualty. I found this patch pretty important, so I will definitely
>  like to demonstrate its benefits. One question remains, would you
>  accept the patch in its current form?

We should bring that back for testing, please.  I need to sit down and
think a bit more about test suites which replicate workloads which we care
about before making any decisions.

One point I would make is that if a workload is only achieving 5% CPU
anyway, we shouldn't optimise for it.  Sure, it's nice to be able to get it
up to 7% but it is much more important to get the 50% CPU workload up to
70%.  The 5% problem is a fiscal one, not an engineering one ;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/