Re: [aarcange@redhat.com: [PATCH] fork vs gup(-fast) fix]

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

Hi Nick,

> > Am I missing any thing?
> 
> I still don't understand why this way is so much better than
> my last proposal. I just wanted to let that simmer down for a 
> few days :) But I'm honestly really just interested in a good
> discussion and I don't mind being sworn at if I'm being stupid,
> but I really want to hear opinions of why I'm wrong too.
> 
> Yes my patch has downsides I'm quite happy to admit. But I just
> don't see that copy-on-fork rather than wrprotect-on-fork is
> the showstopper. To me it seemed nice because it is practically
> just reusing code straight from do_wp_page, and pretty well
> isolated out of the fastpath.

Firstly, I'm very sorry for very long delay responce. This month, I'm
very busy and I don't have enough developing time ;)

Secondly, I have strongly obsession to bugfix. (I guess you alread know it)
but I don't have obsession to bugfix _way_. my patch was made for
creating good discussion, not NAK your patch.

I think your patch is good. but it have few disadvantage.
(yeah, I agree mine have lot disadvantage)

1. using page->flags
   nowadays, page->flags is one of most prime estate in linux.
   as far as possible, we can avoid to use it.
2. don't have GUP_FLAGS_PINNING_PAGE flag
   then, access_process_vm() can decow a page unnecessary.
   it isn't good feature, I think.

   IOW, I don't think "caller transparent" is important.
   minimal side effect is important more. my side-effect mean non direct-io
   effection. I don't mind direct-io path side effection. it is only used DB or
   similar software. then, we can assume a lot of userland usage.


and I was playing your patch in last week. but I conclude I can't shrink
it more.
As far as I understand, Linus don't refuse copy-on-fork itself. he only
refuse messy bugfix patch.
In general, bugfix patch should be backportable to stable tree.

Then, I think step-by-step development is better.

1. at first, merge wrprotect-on-fork.
2. improve speed.

What do you think?


btw,
Linus give me good inspiration. if page pinning happend, the patch
is guranteed to grabbed only one process.
then, we can put pinning-count and some additional information
into anon_vma. it can avoid to use page->flags although we implement 
copy-on-fork. maybe.


HOWEVER, if you really hate my approach, please don't hesitate to tell it.
I don't hope submit your disliked patch. I respect linus, but I respect you too.




--
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>