On 10/12/2011 03:20 PM, Andrew Morton wrote:
On Wed, 12 Oct 2011 09:09:17 -0400
Rik van Riel<riel@xxxxxxxxxx> wrote:
The problem is that we may be dealing with bursts, not steady
states of allocations. Without knowing the size of a burst,
we have no idea when we should wake up kswapd to get enough
memory freed ahead of the application's allocations.
That problem remains with this patch - it just takes a larger burst.
Unless the admin somehow manages to configure the tunable large enough
to cover the largest burst, and there aren't other applications
allocating memory during that burst, and the time between bursts is
sufficient for kswapd to be able to sufficiently replenish free-page
reserves. All of which sounds rather unlikely.
It depends on the system. For a setup which is packed to
the brim with workloads, this patch is not likely to help.
On the other hand, on a system that is packed to the brim
with workloads, you are unlikely to get low latencies anyway.
For situations where people really care about low latencies,
I imagine having dedicated hardware for a workload is not at
all unusual, and the patch works for that.
Look, please don't go bending over backwards like this to defend a bad
patch. It's a bad patch! It would be better not to have to merge it.
Let's do something better.
I would love it if we could come up with something better,
and have thought about it a lot.
However, so far we do not seem to have an alternative yet :(
Do we actually have a real-world application which is hurting from
this?
Satoru-san?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>