(Please CC: me,)
Hi,
I've recently come across someone porting some code
from windows that trys to implement an efficient
memory pool using some VM tricks. I have no idea if
linux has an equivalent to this feature (described
below), and wouldn't know what to even search for to
find out.
What this mempool wants to do is to be able to
allocate a block of memory and tell the kernel which
pages from it can be outright discarded, instead of
swapped out when memory starts to get crowded.
Now, from looking at mel's docs, it looks to me like
this would mean letting the application directly
mark pages clean. But it would also mean finding any
swapped out versions of this page and deallocating
them, otherwise if the page is discarded and then
used again, time would be wasted swapping in garbage.
I'm going to keep reading. If this is already
implemented, or if the efficiency gains would be
nil, somebody yell at me before I start crashing my
kernel with attempts at doing this myself. :-) It
seems so trivial after all...
Thanks,
Ted Kaminski
On Thu, Aug 14, 2003 at 09:17:07PM -0500, [email protected] wrote:
> What this mempool wants to do is to be able to
> allocate a block of memory and tell the kernel which
> pages from it can be outright discarded, instead of
> swapped out when memory starts to get crowded.
I think you might be able to get what you want with madvise() or perhaps
by mmap()ing new clean pages on top of the pages you want to throw away.
> I'm going to keep reading. If this is already
> implemented, or if the efficiency gains would be
> nil, somebody yell at me before I start crashing my
I would not implement this unless you either know you have a problem
with your mempool swap speed or you are bored. I doubt it is going
to help a lot, and it will certainly simplify your code to leave it
out. If you later find that you have performance problems you can
look into this again.
Thanks,
Jim
[email protected] wrote:
> What this mempool wants to do is to be able to
> allocate a block of memory and tell the kernel which
> pages from it can be outright discarded, instead of
> swapped out when memory starts to get crowded.
You can call madvise(start, length, MADV_DONTNEED),
or you can mmap() fresh empty pages into the region.
I have no idea if either of these methods is efficient enough to be
useful. Also, I don't know whether mmap() would create multiple VMAs,
or if it is clever enough to merge adjacent vmas of anonymous private
mappings regardles of offset.
The ideal implementation would give the kernel the _option_ of
discarding pages until they are next touched, so that they are
discarded when there is memory pressure but retained if not, avoiding
the unnecessary zero-fill and cache flush.
Unfortunately, though much discussed a long time ago, the kernel
offers no service like this.
-- Jamie
On Fri, Aug 15, 2003 at 02:56:02PM -0500, [email protected] wrote:
> Is madvise required to result in zero filled pages
> by a standard, or is this just the commonly accepted
> behavior?
I believe it is the standard for clean pages, though someone else will have
to point out where...
Jamie Lokier wrote:
> You can call madvise(start, length, MADV_DONTNEED),
> or you can mmap() fresh empty pages into the region.
madvise appears to be exactly what I'm looking for.
(almost...)
> I have no idea if either of these methods is
efficient enough to be
> useful. Also, I don't know whether mmap() would
create multiple VMAs,
> or if it is clever enough to merge adjacent vmas
of anonymous private
> mappings regardles of offset.
Enough possible pitfalls that madvise becomes the
better solution.
> The ideal implementation would give the kernel the
_option_ of
> discarding pages until they are next touched, so
that they are
> discarded when there is memory pressure but
retained if not, avoiding
> the unnecessary zero-fill and cache flush.
Is madvise required to result in zero filled pages
by a standard, or is this just the commonly accepted
behavior?
> -- Jamie
Thanks a bunch,
Ted
Mike Fedyk wrote:
> On Fri, Aug 15, 2003 at 02:56:02PM -0500, [email protected] wrote:
> > Is madvise required to result in zero filled pages
> > by a standard, or is this just the commonly accepted
> > behavior?
>
> I believe it is the standard for clean pages, though someone else will have
> to point out where...
That's the answer to a different question.
The unanswered question is: what should madvise(MADV_DONTNEED) do,
given dirty pages?
man madvise(*) says that it zero-fills anonymous private mappings, and
restores private file-backed mappings to the original file pages.
That is not surprising, as the CPU-friendly semantic is more
complicated to implement, needing an extra flag in the page table
(or rmap structure).
-- Jamie
Followup to: <[email protected]>
By author: Jamie Lokier <[email protected]>
In newsgroup: linux.dev.kernel
>
> Mike Fedyk wrote:
> > On Fri, Aug 15, 2003 at 02:56:02PM -0500, [email protected] wrote:
> > > Is madvise required to result in zero filled pages
> > > by a standard, or is this just the commonly accepted
> > > behavior?
> >
> > I believe it is the standard for clean pages, though someone else will have
> > to point out where...
>
> That's the answer to a different question.
>
> The unanswered question is: what should madvise(MADV_DONTNEED) do,
> given dirty pages?
>
> man madvise(*) says that it zero-fills anonymous private mappings, and
> restores private file-backed mappings to the original file pages.
>
> That is not surprising, as the CPU-friendly semantic is more
> complicated to implement, needing an extra flag in the page table
> (or rmap structure).
>
Sounds entirely reasonable.
It *would* be nice with a way to be able to say to the kernel "you may
discard this but if so I want SIGSEGV", for things like LPSM and the
like.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
[email protected] said:
> It *would* be nice with a way to be able to say to the kernel "you may
> discard this but if so I want SIGSEGV", for things like LPSM and the
> like.
Yeah, UML could put this to good use, as well...
Jeff