Messages in this thread | | | From | Nick Piggin <> | Subject | Re: patch: improve generic_file_buffered_write() (2nd try 1/2) | Date | Sat, 8 Sep 2007 17:14:09 +1000 |
| |
On Saturday 08 September 2007 07:00, Goswin von Brederlow wrote: > Nick Piggin <nickpiggin@yahoo.com.au> writes: > > Anyway, there are fixes for this deadlock in Andrew's -mm tree, but > > also a workaround for the NFSD problem in git commit 29dbb3fc. Did > > you try a later kernel to see if it is fixed there? > > I had a chance to look up that commit (git clone took a while so sorry > for writing 2 mails). It is present in 2.6.23-rc5 so I already noticed > it when merging our patch in 2.6.23-rc5. > > Upon closer reading of the patch though I see that it will indeed > prevent writes by the nfsd to be split smaller than PAGE_SIZE and it > will cause filemap_copy_from_user[_iovec] to be called with a source > spanning multwhat to do in cambridge pubiple pages.
OK, good.
> So the commit 29dbb3fc should have a simmilar, slightly better even, > gain for the nfsd and other kernel space segments. But it will not > improve writes from user space, where ~14% of the commits were saved > during a days work for me. > > > Now I have a question about fault_in_pages_readable(). Can I call that > for multiple pages and then call __grab_cache_page() without risking > one of the pages from getting lost again and causing a deadlock?
No. The existing mainline code is buggy, and it is just hoping that the userspace page does not get paged out between the fault_in_pages and the subsequent copy_from_user.
If you do multiple fault_in_pages_readable(), you probably have less chance of deadlocking, but on the 2nd call, you might still have to wait for a long time to page in, during which time the 1st page may get paged out.
But there is a proper solution in -mm with the write_begin aop. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |