From: Izik Eidus <ieidus@redhat.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Rik van Riel <riel@redhat.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
aarcange@redhat.com, chrisw@redhat.com, alan@lxorguk.ukuu.org.uk,
device@lanana.org, linux-mm@kvack.org, nickpiggin@yahoo.com.au
Subject: Re: [PATCH 3/6] ksm: change the KSM_REMOVE_MEMORY_REGION ioctl.
Date: Wed, 06 May 2009 18:27:26 +0300 [thread overview]
Message-ID: <4A01AC5E.6000906@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0905061110470.3519@blonde.anvils>
Hugh Dickins wrote:
>
> If KSM is to behave in the usual madvise way, it'll need to be informed
> of unmaps. And I suspect it may need to be informed of them, even if we
> let it continue to apply to empty address space. Because even with your
> more limited unsigned int nrpages interface, the caller can specify an
> enormous range on 64-bit, and ksm.c be fully occupied just incrementing
> from one absent page to the next.
That is a good point that i didnt think about it.
It is possible to make ksm "unmaped memory" aware by using find_vma(),
and skipped non mapped area.
But that start to look bad... (I can make that just by every place that
if_present_pte() fail, and then dont even hurt the scaning performence,
beacuse i will just check it when the first virtual address is not present)
But why not go go step by step?
We can first start with this ioctl interface, later when we add swapping
to the pages, we can have madvice, and still (probably easily) support
the ioctls by just calling from inside ksm the madvice functions for
that specific address)
I want to see ksm use madvice, but i believe it require some more
changes to mm/*.c, so it probably better to start with merging it when
it doesnt touch alot of stuff outisde ksm.c, and then to add swapping
and after that add madvice support (when the pages are swappable,
everyone can use it)
What you think about that?
> mmap's vma ranges confine the space
> to be searched, and instantiated pagetables confine it further: I think
> you're either going to need to rely upon those to confine your search
> area, or else enhance your own data structures to confine it.
>
> But I do appreciate the separation you've kept so far,
> and wouldn't want to tie it all together too closely.
>
> Hugh
>
> p.s. I wish you'd chosen different name than KSM - the kernel
> has supported shared memory for many years - and notice ksm.c itself
> says "Memory merging driver". "Merge" would indeed have been a less
> ambiguous term than "Share", but I think too late to change that now
> - except possibly in the MADV_ flag names?
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-05-06 15:27 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-04 22:25 [PATCH 0/6] ksm changes (v2) Izik Eidus
2009-05-04 22:25 ` [PATCH 1/6] ksm: limiting the num of mem regions user can register per fd Izik Eidus
2009-05-04 22:25 ` [PATCH 2/6] ksm: dont allow overlap memory addresses registrations Izik Eidus
2009-05-04 22:25 ` [PATCH 3/6] ksm: change the KSM_REMOVE_MEMORY_REGION ioctl Izik Eidus
2009-05-04 22:25 ` [PATCH 4/6] ksm: change the prot handling to use the generic helper functions Izik Eidus
2009-05-04 22:25 ` [PATCH 5/6] ksm: build system make it compile for all archs Izik Eidus
2009-05-04 22:25 ` [PATCH 6/6] ksm: use another miscdevice minor number Izik Eidus
2009-05-06 0:55 ` Rik van Riel
2009-05-06 0:54 ` [PATCH 5/6] ksm: build system make it compile for all archs Rik van Riel
2009-05-06 0:54 ` [PATCH 4/6] ksm: change the prot handling to use the generic helper functions Rik van Riel
2009-05-06 0:53 ` [PATCH 3/6] ksm: change the KSM_REMOVE_MEMORY_REGION ioctl Rik van Riel
2009-05-06 8:38 ` Izik Eidus
2009-05-06 11:16 ` Hugh Dickins
2009-05-06 13:34 ` Andrea Arcangeli
2009-05-06 13:56 ` Izik Eidus
2009-05-06 16:41 ` Hugh Dickins
2009-05-06 16:49 ` Chris Wright
2009-05-06 16:57 ` Hugh Dickins
2009-05-06 17:47 ` Andrea Arcangeli
2009-05-06 16:59 ` Izik Eidus
2009-05-07 11:31 ` Andrea Arcangeli
2009-05-07 13:13 ` Hugh Dickins
2009-05-07 13:23 ` Andrea Arcangeli
2009-05-06 14:25 ` Hugh Dickins
2009-05-06 14:45 ` Andrea Arcangeli
2009-05-06 15:36 ` Chris Wright
2009-05-06 15:27 ` Izik Eidus [this message]
2009-05-06 16:14 ` Chris Wright
2009-05-06 16:36 ` Hugh Dickins
2009-05-06 17:09 ` Chris Wright
2009-05-06 17:54 ` Hugh Dickins
2009-05-06 16:26 ` Hugh Dickins
2009-05-06 16:58 ` Izik Eidus
2009-05-06 23:59 ` Chris Wright
2009-05-07 2:41 ` Rik van Riel
2009-05-06 0:43 ` [PATCH 2/6] ksm: dont allow overlap memory addresses registrations Rik van Riel
2009-05-06 9:46 ` Izik Eidus
2009-05-06 12:26 ` Rik van Riel
2009-05-06 12:39 ` Izik Eidus
2009-05-06 13:17 ` Andrea Arcangeli
2009-05-06 13:28 ` Hugh Dickins
2009-05-06 14:02 ` Izik Eidus
2009-05-06 17:11 ` Hugh Dickins
2009-05-06 14:09 ` Andrea Arcangeli
2009-05-06 14:21 ` Alan Cox
2009-05-06 14:46 ` Hugh Dickins
2009-05-06 14:56 ` Andrea Arcangeli
2009-05-06 23:55 ` Minchan Kim
2009-05-07 0:19 ` Chris Wright
2009-05-07 10:46 ` Andrea Arcangeli
2009-05-07 12:01 ` Minchan Kim
2009-05-06 14:57 ` Izik Eidus
2009-05-06 0:40 ` [PATCH 1/6] ksm: limiting the num of mem regions user can register per fd Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2009-05-02 22:16 [PATCH 0/6] ksm changes Izik Eidus
2009-05-02 22:16 ` [PATCH 1/6] ksm: limiting the num of mem regions user can register per fd Izik Eidus
2009-05-02 22:16 ` [PATCH 2/6] ksm: dont allow overlap memory addresses registrations Izik Eidus
2009-05-02 22:16 ` [PATCH 3/6] ksm: change the KSM_REMOVE_MEMORY_REGION ioctl Izik Eidus
2009-05-04 19:43 ` Hugh Dickins
2009-05-04 20:37 ` Izik Eidus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A01AC5E.6000906@redhat.com \
--to=ieidus@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chrisw@redhat.com \
--cc=device@lanana.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).