Nick Piggin wrote:
Rik van Riel wrote:
With lazy freeing of anonymous pages through MADV_FREE, performance of
the MySQL sysbench workload more than doubles on my quad-core system.
OK, I've run some tests on a 16 core Opteron system, both sysbench with
MySQL 5.33 (set up as described in the fre
On Fri, 4 May 2007, Ulrich Drepper wrote:
>
> I don't want to judge the numbers since I cannot but I want to make an
> observations: even if in the SMP case MADV_FREE turns out to not be a
> bigger boost then there is still the UP case to keep in mind where Rik
> measured a significant speed-up.
Jakub Jelinek wrote:
On Tue, May 08, 2007 at 04:12:00PM +1000, Nick Piggin wrote:
I didn't actually check system and user times for the mysql
benchmark, but that's exactly what I had in mind when I
mentioned the poor cache behaviour this patch could cause. I
definitely did see user times go up
Rik van Riel wrote:
Nick Piggin wrote:
We have percpu and cache affine page allocators, so when
userspace just frees a page, it is likely to be cache hot, so
we want to free it up so it can be reused by this CPU ASAP.
Likewise, when we newly allocate a page, we want it to be one
that is cache h
On Tue, May 08, 2007 at 04:12:00PM +1000, Nick Piggin wrote:
> I didn't actually check system and user times for the mysql
> benchmark, but that's exactly what I had in mind when I
> mentioned the poor cache behaviour this patch could cause. I
> definitely did see user times go up in benchmarks whe
Nick Piggin wrote:
We have percpu and cache affine page allocators, so when
userspace just frees a page, it is likely to be cache hot, so
we want to free it up so it can be reused by this CPU ASAP.
Likewise, when we newly allocate a page, we want it to be one
that is cache hot on this CPU.
Act
Rik van Riel wrote:
Nick Piggin wrote:
OK, sure. I think we need more numbers though.
Thinking about the issue some more, I think I know just the
number we might want to know.
It is pretty obvious that the kernel needs to do less work
with the MADV_FREE code present. However, it is possibl
Ulrich Drepper wrote:
Rik van Riel wrote:
It's trivial to merge the MADV_FREE #defines into the kernel
though, and aliasing MADV_FREE to MADV_DONTNEED for the time
being is a one-liner - just an extra constant into the big
switch statement in sys_madvise().
Until the semantics of the implement
Rik van Riel wrote:
It's trivial to merge the MADV_FREE #defines into the kernel
though, and aliasing MADV_FREE to MADV_DONTNEED for the time
being is a one-liner - just an extra constant into the big
switch statement in sys_madvise().
Until the semantics of the implementation is cut into stone
Ulrich Drepper wrote:
Rik van Riel wrote:
I think that maybe for 2.6.22 we should just alias MADV_FREE
to run with the MADV_DONTNEED functionality, so that the glibc
people can make the change on their side while we figure out
what will be the best thing to do on the kernel side.
No need for t
Rik van Riel wrote:
I think that maybe for 2.6.22 we should just alias MADV_FREE
to run with the MADV_DONTNEED functionality, so that the glibc
people can make the change on their side while we figure out
what will be the best thing to do on the kernel side.
No need for that. We can later exte
Nick Piggin wrote:
OK, sure. I think we need more numbers though.
Thinking about the issue some more, I think I know just the
number we might want to know.
It is pretty obvious that the kernel needs to do less work
with the MADV_FREE code present. However, it is possible
that userspace needs
Nick Piggin wrote:
> I literally have about 4 or 5 new page flags I'd like to add today :) I
> can't of course, because we have very few spare ones left.
I remember Rik saying that if need be he can (try to?) think of a method
to implement it without a page flag.
--
➧ Ulrich Drepper ➧ Red Hat, I
Rik van Riel wrote:
Nick Piggin wrote:
Rik van Riel wrote:
With lazy freeing of anonymous pages through MADV_FREE, performance of
the MySQL sysbench workload more than doubles on my quad-core system.
OK, I've run some tests on a 16 core Opteron system, both sysbench with
MySQL 5.33 (set up
Ulrich Drepper wrote:
Nick Piggin wrote:
What I found is that, on this system, MADV_FREE performance improvement
was in the noise when you look at it on top of the MADV_DONTNEED glibc
and down_read(mmap_sem) patch in sysbench.
I don't want to judge the numbers since I cannot but I want to ma
Nick Piggin wrote:
> What I found is that, on this system, MADV_FREE performance improvement
> was in the noise when you look at it on top of the MADV_DONTNEED glibc
> and down_read(mmap_sem) patch in sysbench.
I don't want to judge the numbers since I cannot but I want to make an
observations: ev
Nick Piggin wrote:
Rik van Riel wrote:
With lazy freeing of anonymous pages through MADV_FREE, performance of
the MySQL sysbench workload more than doubles on my quad-core system.
OK, I've run some tests on a 16 core Opteron system, both sysbench with
MySQL 5.33 (set up as described in the fre
Rik van Riel wrote:
With lazy freeing of anonymous pages through MADV_FREE, performance of
the MySQL sysbench workload more than doubles on my quad-core system.
OK, I've run some tests on a 16 core Opteron system, both sysbench with
MySQL 5.33 (set up as described in the freebsd vs linux page),
With lazy freeing of anonymous pages through MADV_FREE, performance of
the MySQL sysbench workload more than doubles on my quad-core system.
Madvise with MADV_FREE is used by applications to tell the kernel that
memory no longer contains useful data and can be reclaimed by the
kernel if it is nee
19 matches
Mail list logo
