Hi Jakub,
> That would mean an additional syscall. Furthermore, if you allocate a big
> chunk of memory, dirty it, then free (with madvise (MADV_FREE)) it and soon
> allocate the same size of memory again, it is better to start that with
> non-dirty memory, it might be that this time you e.g. d
On Mon, Apr 16, 2007 at 11:10:39AM -0500, Anton Blanchard wrote:
> > Making the pte clean also needs to clear the hardware writable
> > bit on architectures where we do pte dirtying in software.
> >
> > If we don't, we would have corruption problems all over the VM,
> > for example in the code aro
Hi,
> Making the pte clean also needs to clear the hardware writable
> bit on architectures where we do pte dirtying in software.
>
> If we don't, we would have corruption problems all over the VM,
> for example in the code around pte_clean_one :)
>
> >But as Linus recently said, even hardware
Rik van Riel wrote:
Nick Piggin wrote:
The lazy freeing is aimed at avoiding page faults on memory
that is freed and later realloced, which is quite a common
thing in many workloads.
I would be interested to see how it performs and what these
workloads look like, although we do need to fix t
Nick Piggin wrote:
The lazy freeing is aimed at avoiding page faults on memory
that is freed and later realloced, which is quite a common
thing in many workloads.
I would be interested to see how it performs and what these
workloads look like, although we do need to fix the basic glibc and
mad
Rik van Riel wrote:
Nick Piggin wrote:
Nick Piggin wrote:
Eric Dumazet wrote:
ah ok, this is because accessed/dirty bits are set by hardware and
not a page fault.
No it isn't.
That is to say, it isn't required for correctness. But if the
question was about avoiding a fault, then yes
Nick Piggin wrote:
Nick Piggin wrote:
Eric Dumazet wrote:
Two things can happen here.
If this program used the pages before the kernel needed
them, the program will be reusing its old pages.
ah ok, this is because accessed/dirty bits are set by hardware and
not a page fault.
No it i
Nick Piggin wrote:
Eric Dumazet wrote:
Two things can happen here.
If this program used the pages before the kernel needed
them, the program will be reusing its old pages.
ah ok, this is because accessed/dirty bits are set by hardware and not
a page fault.
No it isn't.
That is to s
Eric Dumazet wrote:
Rik van Riel a écrit :
Eric Dumazet wrote:
Rik van Riel a écrit :
Make it possible for applications to have the kernel free memory
lazily. This reduces a repeated free/malloc cycle from freeing
pages and allocating them, to just marking them freeable. If the
applicatio
Rik van Riel a écrit :
Eric Dumazet wrote:
Rik van Riel a écrit :
Make it possible for applications to have the kernel free memory
lazily. This reduces a repeated free/malloc cycle from freeing
pages and allocating them, to just marking them freeable. If the
application wants to reuse them be
Eric Dumazet wrote:
Rik van Riel a écrit :
Make it possible for applications to have the kernel free memory
lazily. This reduces a repeated free/malloc cycle from freeing
pages and allocating them, to just marking them freeable. If the
application wants to reuse them before the kernel needs th
Rik van Riel a écrit :
Make it possible for applications to have the kernel free memory
lazily. This reduces a repeated free/malloc cycle from freeing
pages and allocating them, to just marking them freeable. If the
application wants to reuse them before the kernel needs the memory,
not even a
12 matches
Mail list logo
