Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

On 6/10/2018 3:02 PM, Jaromír Doleček wrote: 2018-05-12 21:24 GMT+02:00 Chuck Silvers : the problem with keeping the pages locked (ie. PG_BUSY) while accessing the user address space is that it can lead to deadlock if the page Meanwhile I've tested this scenario - wrote a test program to do

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

2018-05-12 21:24 GMT+02:00 Chuck Silvers : > the problem with keeping the pages locked (ie. PG_BUSY) while accessing > the user address space is that it can lead to deadlock if the page Meanwhile I've tested this scenario - wrote a test program to do mmap(2) for file, then calling write() using

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

On Sun, May 13, 2018 at 02:59:50PM +0200, Jaromr Dole?ek wrote: > 2018-05-12 21:24 GMT+02:00 Chuck Silvers : > > the problem with keeping the pages locked (ie. PG_BUSY) while accessing > > the user address space is that it can lead to deadlock if the page > > we are accessing via

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

2018-05-12 21:24 GMT+02:00 Chuck Silvers : > the problem with keeping the pages locked (ie. PG_BUSY) while accessing > the user address space is that it can lead to deadlock if the page > we are accessing via the kernel mapping is the same page that we are > accessing via the user

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

t map from changing identity while still allowing normal page faults to happen on the user mapping. there are probably less intrusive ways to attack the problem at hand, but the above approach seemed like the best way to go in the long run. I was hoping the emap thing would work for the shorter te

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

2018-05-12 7:07 GMT+02:00 Michael van Elst : > On Fri, May 11, 2018 at 05:28:18PM +0200, Jaromír Dole?ek wrote: >> I've implemented a tweak to read-ahead code to skip the full >> read-ahead if last page of the range is already in cache, this >> improved things a lot: > > That

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

On Fri, May 11, 2018 at 05:28:18PM +0200, Jaromír Dole?ek wrote: > I've implemented a tweak to read-ahead code to skip the full > read-ahead if last page of the range is already in cache, this > improved things a lot: That looks a bit like a hack. Can't you just call uvm_pagelookup() to

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

> On May 11, 2018, at 8:28 AM, Jaromír Doleček > wrote: > > I've modified the uvm_bio.c code to use direct map for amd64. Change > seems to be stable, I've also run 'build.sh tools' to test out the > system, build suceeded and I didn't observe any problems with >

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

or general case. Jaromir 2018-04-19 22:39 GMT+02:00 Jaromír Doleček <jaromir.dole...@gmail.com>: > I've finally got my test rig setup, so was able to check the > performance difference when using emap. > > Good news there is significant speedupon NVMe device, without > observ

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

I've finally got my test rig setup, so was able to check the performance difference when using emap. Good news there is significant speedupon NVMe device, without observing any bad side effects so far. I've setup a test file of 2G, smaller than RAM to fit all in cache, test was: dd if=foo

re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

ason we stopped using emap is that there were performance issues. rmind? .mrg.

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

n't just use the direct map for this on amd64 and similar platforms? Right, we could/should use emap. I haven't realized emap is actually already implemented. It's currently used for pipe for the loan/"direct" write. I don't know anything about emap thought. Are there any known issu

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

On Mon, Apr 02, 2018 at 09:28:43PM +0200, Jaromír Dole?ek wrote: > The only port actually having optimization for emap is x86. Since amd64 > is also the only one supporting direct map, we are really at liberty to pick > either one. I am not sure what you mean here - AFIK alpha and mi

Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86 - emap, direct map

irect map for this on amd64 >> and similar platforms? > > Right, we could/should use emap. I haven't realized emap is actually already > implemented. It's currently used for pipe for the loan/"direct" write. > > I don't know anything about emap thought. Are there any known iss

Re: emap

the status of emap and pipe? ... and encourage our users to use amd64 instead of i386. I'm sorry to intervene, what about WINE? Unless we're going to have it functional on amd64, encouraging is useless. I don't understand your comment. Are you suggesting that a large fraction

Re: emap

hi, Thor Lancelot Simon t...@panix.com writes: On Fri, Nov 25, 2011 at 12:50:58PM +0400, Aleksej Saushev wrote: Mindaugas Rasiukevicius rm...@netbsd.org writes: y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, what's the status of emap and pipe? ... and encourage our

Re: emap

: hi, what's the status of emap and pipe? ... and encourage our users to use amd64 instead of i386. I'm sorry to intervene, what about WINE? Unless we're going to have it functional on amd64, encouraging is useless. I don't understand your comment. Are you

Re: emap

On Mon, 5 Dec 2011 04:19:13 + (UTC) y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: Although I didn't think it'd be necessary to say so until this point, I admit that I myself didn't really understand what Takashi said about recommending amd64 over i386. If the hardware is 32-bit, or

Re: emap

On Fri, Nov 25, 2011 at 12:50:58PM +0400, Aleksej Saushev wrote: Mindaugas Rasiukevicius rm...@netbsd.org writes: y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, what's the status of emap and pipe? ... and encourage our users to use amd64 instead of i386. I'm sorry

Re: emap

Thor Lancelot Simon t...@panix.com writes: On Fri, Nov 25, 2011 at 12:50:58PM +0400, Aleksej Saushev wrote: Mindaugas Rasiukevicius rm...@netbsd.org writes: y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, what's the status of emap and pipe? ... and encourage our users

Re: emap

, what's the status of emap and pipe? ... and encourage our users to use amd64 instead of i386. I'm sorry to intervene, what about WINE? Unless we're going to have it functional on amd64, encouraging is useless. I don't understand your comment. Are you suggesting

Re: emap

y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, what's the status of emap and pipe? If I remember correctly, I could not get real performance improvement of pipe with UVM emap. Higher chances are that it would improve socket performance. Also, pipe has direct I/O disabled

Re: emap

hi, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, what's the status of emap and pipe? If I remember correctly, I could not get real performance improvement of pipe with UVM emap. Higher chances are that it would improve socket performance. Also, pipe has direct I/O disabled

emap

hi, what's the status of emap and pipe? YAMAMOTO Takashi

Re: Using emap for i386/amd64 early during boot

Jean-Yves Migeon jeanyves.mig...@free.fr wrote: Agree with David's point, but it should not be done at function level. Rather higher level interface abstraction. In uvmplock branch, I have already split some x86 pmap bits into pmap_tlb.c and xen_pmap.c modules. More interfaces can be

Re: Using emap for i386/amd64 early during boot

Jean-Yves Migeon jeanyves.mig...@free.fr wrote: As I have yet to understand the inner workings of emap, I'd like to know if it is possible to wrap i386_cpu_switch_pmap() around uvm_emap functions, like this: [...] u_int gen = uvm_emap_gen_return(); i386_cpu_switch_pmap(pmap

Re: Using emap for i386/amd64 early during boot

On Sun, Jun 20, 2010 at 07:45:32PM +0200, Jean-Yves Migeon wrote: For convenience, here's i386_cpu_switch_pmap: I know that a lot of legacy code uses the preprocessor the way that you have in i386_cpu_switch_pmap(), but I don't think that the preprocessor should be used in that way any longer.

Re: Using emap for i386/amd64 early during boot

On 20.06.2010 22:19, David Young wrote: On Sun, Jun 20, 2010 at 07:45:32PM +0200, Jean-Yves Migeon wrote: For convenience, here's i386_cpu_switch_pmap: I know that a lot of legacy code uses the preprocessor the way that you have in i386_cpu_switch_pmap(), but I don't think that the

Re: Using emap for i386/amd64 early during boot

On 20.06.2010 20:00, Mindaugas Rasiukevicius wrote: Jean-Yves Migeonjeanyves.mig...@free.fr wrote: As I have yet to understand the inner workings of emap, I'd like to know if it is possible to wrap i386_cpu_switch_pmap() around uvm_emap functions, like this: [...] u_int gen

Re: Using emap for i386/amd64 early during boot

Jean-Yves Migeon jeanyves.mig...@free.fr wrote: I know that a lot of legacy code uses the preprocessor the way that you have in i386_cpu_switch_pmap(), but I don't think that the preprocessor should be used in that way any longer. In my experience, code that uses the preprocessor

Re: Using emap for i386/amd64 early during boot

On 21.06.2010 00:39, Mindaugas Rasiukevicius wrote: Jean-Yves Migeonjeanyves.mig...@free.fr wrote: I know that a lot of legacy code uses the preprocessor the way that you have in i386_cpu_switch_pmap(), but I don't think that the preprocessor should be used in that way any longer. In my