On Thu, May 07, 2015 at 05:42:08PM +0300, Pavel Emelyanov wrote:
> On 05/07/2015 05:33 PM, Andrea Arcangeli wrote:
> > On Thu, May 07, 2015 at 05:28:46PM +0300, Pavel Emelyanov wrote:
> >> Yup, this is very close to what I did in my set -- introduced a message to
> >> report back to the user-space on read. But my message is more than 8+2*1 bytes,
> >> so we'll have one message for 0xAA API and another one for 0xAB (new) one :)
> >
> > I slightly altered it to fix an issue with packet alignments so it'd
> > be 16bytes.
> >
> > How big is your msg currently? Could we get to use the same API?
>
> Right now it's like this
>
> struct uffd_event {
> __u64 type;
> union {
> struct {
> __u64 addr;
> } pagefault;
>
> struct {
> __u32 ufd;
> } fork;
>
> struct {
> __u64 from;
> __u64 to;
> __u64 len;
> } remap;
> } arg;
> };
>
> where .type is your uffd_msg.event and the rest is event-specific.
So you have two more __u64.
In theory if msg.event == UFFD_EVENT_MREMAP you could have the "from"
encoded in the msg.arg and then userland could read 16 more bytes
knowing it'll get "to len" and we won't have to alter the UFFD_API for
adding new EVENT that requires bigger msg size. But it's probably not
worth it as an enter/exit kernel is way more costly than reading
16 more bytes, if we already know we need 32bytes in the end.
MADV_DONTNEED shouldn't need more bytes than mremap either.
I think it's ok if I enlarge it to 32bytes.
>
> > UFFDIO_REGISTER_MODE_FORK
> >
> > or
> >
> > UFFDIO_REGISTER_MODE_NON_COOPERATIVE would differentiate if you want
> > to register for fork/mremap/dontneed events as well or only the
> > default (UFFD_EVENT_PAGEFAULT).
>
> I planned to use this in UFFDIO_API call -- the uffdio_api.features will
> be in-out argument denoting the bits user needs and reporting what kernel
> can.
Ok I guess in-out and checking api.features is easier than checking
the vma during the fault. That's ok for me, plus if needed the
registration flag can still be added later in addition of the in-out
api.features.
So I also need to error out the UFFDIO_API call if api.features is not
zero, ok?
After those two changes you should be ok with the same API?
We may still need a new API later of course, it's hard to predict the
future and all possible future usages of the userfaultfd... but
perhaps this will be enough...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>