Re: Revisiting uvm_loan() for 'direct' write pipes

2018-05-25 23:19 GMT+02:00 Jason Thorpe : > BTW, I was thinking about this, and I think you need to also handle the case > where you try the ubc_uiomove_direct() case, but then *fall back* onto the > non-direct case if some magic error is returned. > ... > These cache flushes could be potentially

Re: Revisiting uvm_loan() for 'direct' write pipes

On Fri, May 25, 2018 at 10:01:15PM +0200, Jarom??r Dole??ek wrote: > 2018-05-21 21:49 GMT+02:00 Jarom??r Dole??ek : > > It turned out uvm_loan() incurs most of the overhead. I'm still on my > > way to figure what it is exactly which makes it so much slower than > >

Re: Revisiting uvm_loan() for 'direct' write pipes

> On May 25, 2018, at 1:01 PM, Jaromír Doleček > wrote: > > So, I'm actually thinking to change uvm_loan() to not enforce R/O > mappings and leave page attributes without change. It would require > the caller to deal with possible COW or PG_RDONLY if they need to do

Re: Revisiting uvm_loan() for 'direct' write pipes

> On May 21, 2018, at 12:49 PM, Jaromír Doleček > wrote: > > Mostly since I want to > have at least one other consumer of the interface before I consider it > as final, to make sure it covers the general use cases. BTW, I was thinking about this, and I think you

Re: Revisiting uvm_loan() for 'direct' write pipes

2018-05-21 21:49 GMT+02:00 Jaromír Doleček : > It turned out uvm_loan() incurs most of the overhead. I'm still on my > way to figure what it is exactly which makes it so much slower than > uiomove(). I've now pinned the problem down to the pmap_page_protect(...,