On 05/07/2015 06:11 PM, Andrea Arcangeli wrote:
> 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.
Yes, this one only needs an address and length.
> I think it's ok if I enlarge it to 32bytes.
Cool, then we don't need the 2nd API for that :) At least for now.
>>
>>> 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?
Exactly!
> After those two changes you should be ok with the same API?
Yes. Longer message (type + 3 u64-s) and the ability to request for extra
events is all I need. If you're OK with this being in the 0xAA API, then
let's do it. I'll rebase my patches again once this appears in your repo :)
> 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...
-- Pavel
--
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>