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 19:58:21 +0300 [thread overview]
Message-ID: <4A01C1AD.9060802@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0905061706590.4005@blonde.anvils>
Hugh Dickins wrote:
> On Wed, 6 May 2009, Izik Eidus wrote:
>
>> 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?
>>
>
> I think it's the wrong order to follow.
>
> The /dev/ksm interface is fine for your use while it's out of tree,
> but we want to get the user interface right when bringing it into
> mainline. I recall Chris being very clear on that too.
>
> Changing from /dev/ksm to madvise() is not a lot of work, it's mainly
> a matter of deleting code, and tidying up interfaces which would need
> more work anyway (I haven't commented on your curious -EPERMs yet!).
>
> It doesn't involve whether you've enabled swapping or not - let's
> forget the CAP_IPC_LOCK idea, and delegate that issue to limitation
> via sysfs, along with the ability to limit wild overuse of the feature
> - permissions on a sysfs node or something else?
>
> It does nudge towards making some decisions which need to be made
> anyway - that tends to be what a correct interface forces upon you.
> Like the issue of whether to go on covering unmapped areas or not -
> though possibly we could put off that decision, if it's doc'ed
> for now.
>
> And if it only covers mapped areas, then there will need to be a
> VM_flag for it, mainly so mm can call into ksm.c when it's unmapped;
> but I don't see it sinking hooks deeply into mm/*.c.
>
> Hugh
>
Ok, i give up, lets move to madvice(), i will write a patch that move
the whole thing into madvice after i finish here something, but that
ofcurse only if Andrea agree for the move?
WARNING: multiple messages have this Message-ID (diff)
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 19:58:21 +0300 [thread overview]
Message-ID: <4A01C1AD.9060802@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0905061706590.4005@blonde.anvils>
Hugh Dickins wrote:
> On Wed, 6 May 2009, Izik Eidus wrote:
>
>> 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?
>>
>
> I think it's the wrong order to follow.
>
> The /dev/ksm interface is fine for your use while it's out of tree,
> but we want to get the user interface right when bringing it into
> mainline. I recall Chris being very clear on that too.
>
> Changing from /dev/ksm to madvise() is not a lot of work, it's mainly
> a matter of deleting code, and tidying up interfaces which would need
> more work anyway (I haven't commented on your curious -EPERMs yet!).
>
> It doesn't involve whether you've enabled swapping or not - let's
> forget the CAP_IPC_LOCK idea, and delegate that issue to limitation
> via sysfs, along with the ability to limit wild overuse of the feature
> - permissions on a sysfs node or something else?
>
> It does nudge towards making some decisions which need to be made
> anyway - that tends to be what a correct interface forces upon you.
> Like the issue of whether to go on covering unmapped areas or not -
> though possibly we could put off that decision, if it's doc'ed
> for now.
>
> And if it only covers mapped areas, then there will need to be a
> VM_flag for it, mainly so mm can call into ksm.c when it's unmapped;
> but I don't see it sinking hooks deeply into mm/*.c.
>
> Hugh
>
Ok, i give up, lets move to madvice(), i will write a patch that move
the whole thing into madvice after i finish here something, but that
ofcurse only if Andrea agree for the move?
--
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 17:01 UTC|newest]
Thread overview: 112+ 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 ` 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 ` Izik Eidus
2009-05-04 22:25 ` [PATCH 2/6] ksm: dont allow overlap memory addresses registrations Izik Eidus
2009-05-04 22:25 ` 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 ` 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 ` 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 ` Izik Eidus
2009-05-04 22:25 ` [PATCH 6/6] ksm: use another miscdevice minor number Izik Eidus
2009-05-04 22:25 ` Izik Eidus
2009-05-06 0:55 ` Rik van Riel
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 ` 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:54 ` 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 0:53 ` Rik van Riel
2009-05-06 8:38 ` Izik Eidus
2009-05-06 8:38 ` Izik Eidus
2009-05-06 11:16 ` Hugh Dickins
2009-05-06 11:16 ` Hugh Dickins
2009-05-06 13:34 ` Andrea Arcangeli
2009-05-06 13:34 ` Andrea Arcangeli
2009-05-06 13:56 ` Izik Eidus
2009-05-06 13:56 ` Izik Eidus
2009-05-06 16:41 ` Hugh Dickins
2009-05-06 16:41 ` Hugh Dickins
2009-05-06 16:49 ` Chris Wright
2009-05-06 16:49 ` Chris Wright
2009-05-06 16:57 ` Hugh Dickins
2009-05-06 16:57 ` Hugh Dickins
2009-05-06 17:47 ` Andrea Arcangeli
2009-05-06 17:47 ` Andrea Arcangeli
2009-05-06 16:59 ` Izik Eidus
2009-05-06 16:59 ` Izik Eidus
2009-05-07 11:31 ` Andrea Arcangeli
2009-05-07 11:31 ` Andrea Arcangeli
2009-05-07 13:13 ` Hugh Dickins
2009-05-07 13:13 ` Hugh Dickins
2009-05-07 13:23 ` Andrea Arcangeli
2009-05-07 13:23 ` Andrea Arcangeli
2009-05-06 14:25 ` Hugh Dickins
2009-05-06 14:25 ` Hugh Dickins
2009-05-06 14:45 ` Andrea Arcangeli
2009-05-06 14:45 ` Andrea Arcangeli
2009-05-06 15:36 ` Chris Wright
2009-05-06 15:36 ` Chris Wright
2009-05-06 15:27 ` Izik Eidus
2009-05-06 15:27 ` Izik Eidus
2009-05-06 16:14 ` Chris Wright
2009-05-06 16:14 ` Chris Wright
2009-05-06 16:36 ` Hugh Dickins
2009-05-06 16:36 ` Hugh Dickins
2009-05-06 17:09 ` Chris Wright
2009-05-06 17:09 ` Chris Wright
2009-05-06 17:54 ` Hugh Dickins
2009-05-06 17:54 ` Hugh Dickins
2009-05-06 16:26 ` Hugh Dickins
2009-05-06 16:26 ` Hugh Dickins
2009-05-06 16:58 ` Izik Eidus [this message]
2009-05-06 16:58 ` Izik Eidus
2009-05-06 23:59 ` Chris Wright
2009-05-06 23:59 ` Chris Wright
2009-05-07 2:41 ` Rik van Riel
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 0:43 ` Rik van Riel
2009-05-06 9:46 ` Izik Eidus
2009-05-06 9:46 ` Izik Eidus
2009-05-06 12:26 ` Rik van Riel
2009-05-06 12:26 ` Rik van Riel
2009-05-06 12:39 ` Izik Eidus
2009-05-06 12:39 ` Izik Eidus
2009-05-06 13:17 ` Andrea Arcangeli
2009-05-06 13:17 ` Andrea Arcangeli
2009-05-06 13:28 ` Hugh Dickins
2009-05-06 13:28 ` Hugh Dickins
2009-05-06 14:02 ` Izik Eidus
2009-05-06 14:02 ` Izik Eidus
2009-05-06 17:11 ` Hugh Dickins
2009-05-06 17:11 ` Hugh Dickins
2009-05-06 14:09 ` Andrea Arcangeli
2009-05-06 14:09 ` Andrea Arcangeli
2009-05-06 14:21 ` Alan Cox
2009-05-06 14:21 ` Alan Cox
2009-05-06 14:46 ` Hugh Dickins
2009-05-06 14:46 ` Hugh Dickins
2009-05-06 14:56 ` Andrea Arcangeli
2009-05-06 14:56 ` Andrea Arcangeli
2009-05-06 23:55 ` Minchan Kim
2009-05-06 23:55 ` Minchan Kim
2009-05-07 0:19 ` Chris Wright
2009-05-07 0:19 ` Chris Wright
2009-05-07 10:46 ` Andrea Arcangeli
2009-05-07 10:46 ` Andrea Arcangeli
2009-05-07 12:01 ` Minchan Kim
2009-05-07 12:01 ` Minchan Kim
2009-05-06 14:57 ` Izik Eidus
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
2009-05-06 0:40 ` 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-02 22:16 ` Izik Eidus
2009-05-04 19:43 ` Hugh Dickins
2009-05-04 19:43 ` Hugh Dickins
2009-05-04 20:37 ` Izik Eidus
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=4A01C1AD.9060802@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.