headers
Mindaugas Rasiukevicius | 22 Aug 2009 14:23
Picon

Re: uarea swap-out

matthew green <mrg <at> eterna.com.au> wrote:
> 
> i'm really curious how this affects platforms with very
> few hardware pages, like acorn26.
> 

I cannot measure that empirically, therefore CC'ing port-acorn26 and
port-acorn32 lists. There are few points regarding this:

- Merge of lwp_cache and uarea (it puts struct lwp, pcb and kstack together)
  should have positive effect i.e. it would increase the utilisation of pages.

- The criteria when LWP can be swapped-out is relatively strict i.e. there
  are already many states when it cannot, see swappable() in uvm_glue.c.

- If your machine starts swapping uareas, I think it is already quite a
  hammer, especially for machines like acorn26/32.

Newer patch removing uarea swap-out:

http://www.netbsd.org/~rmind/uarea_swapout3.diff

By the way, patch cuts ~4k from amd64 kernel size.

> 
> .mrg.

--

-- 
Mindaugas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Pumford | 24 Aug 2009 21:05
Picon
Picon

Re: uarea swap-out

Mindaugas Rasiukevicius wrote:
> matthew green <mrg <at> eterna.com.au> wrote:
>> i'm really curious how this affects platforms with very
>> few hardware pages, like acorn26.
>>
> 
> I cannot measure that empirically, therefore CC'ing port-acorn26 and
> port-acorn32 lists. There are few points regarding this:
> 
> - Merge of lwp_cache and uarea (it puts struct lwp, pcb and kstack together)
>   should have positive effect i.e. it would increase the utilisation of pages.
> 
> - The criteria when LWP can be swapped-out is relatively strict i.e. there
>   are already many states when it cannot, see swappable() in uvm_glue.c.
> 
> - If your machine starts swapping uareas, I think it is already quite a
>   hammer, especially for machines like acorn26/32.
> 
> Newer patch removing uarea swap-out:
> 
I'll give it a try on an acorn32 machine next weekend. I assume the 
patch is for a current kernel.

Mike
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 25 Aug 2009 22:04
Picon

Re: uarea swap-out

hi,

> matthew green <mrg <at> eterna.com.au> wrote:
>> 
>> i'm really curious how this affects platforms with very
>> few hardware pages, like acorn26.

saving some pages is one thing, but i think the more important point of
swapping is thrashing control.  ie. by suspending processes in turn,
you might be able to run others with less vm pressure.

>> 
> 
> I cannot measure that empirically, therefore CC'ing port-acorn26 and
> port-acorn32 lists. There are few points regarding this:
> 
> - Merge of lwp_cache and uarea (it puts struct lwp, pcb and kstack together)
>   should have positive effect i.e. it would increase the utilisation of pages.
> 
> - The criteria when LWP can be swapped-out is relatively strict i.e. there
>   are already many states when it cannot, see swappable() in uvm_glue.c.
> 
> - If your machine starts swapping uareas, I think it is already quite a
>   hammer, especially for machines like acorn26/32.
> 
> Newer patch removing uarea swap-out:
> 
> http://www.netbsd.org/~rmind/uarea_swapout3.diff

calling uvm_fault_wire on wired pages seems wrong.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mindaugas Rasiukevicius | 28 Aug 2009 23:59
Picon

Re: uarea swap-out

Hello,

yamt <at> mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > http://www.netbsd.org/~rmind/uarea_swapout3.diff
> 
> calling uvm_fault_wire on wired pages seems wrong.
> 

Latest one:

http://www.netbsd.org/~rmind/uarea_swapout4.diff

--

-- 
Mindaugas
Permalink | Reply | 0 comments |
headers
Andrew Doran | 29 Aug 2009 11:49
Picon

Re: uarea swap-out

On Fri, Aug 28, 2009 at 10:59:06PM +0100, Mindaugas Rasiukevicius wrote:

> http://www.netbsd.org/~rmind/uarea_swapout4.diff

- Suggest leaving the ps keywords in place and documented.  Removing them
  could break scripts, and leaving them in serves as a reminder not to reuse
  the same flag letters in the display.  top and systat are by and large
  visual so I don't have the same concern about them.  Benfit of removing
  them is only cosmetic.

- You can probably get rid of XS_CTL_DATA_ONSTACK.

- lwp_t::l_swaplock: worth leaving as a reserved field?

- uvmexp_sysctl::swapins, swapouts: would leave these and not rename so you
  don't break compilation of third party software.  Consider the various X
  widgets that display graphs and so on.

- As an aside, elimination of pmap_collect() gets us a closer to the
  simplification of pmap locking that I proposed earlier this year - where
  MD page manipluation are implicitly locked by caller using the containing
  object's lock (uvm_object and/or amap). It also allows lockless
  pmap_extract() to be safe again - I can't remember if I disabled this. It
  was unsafe because pmap_collect() was a "side channel" where PTEs and so
  on could be ripped out from under the process even with the correct
  uvm_object/amap locked.

Thanks!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mindaugas Rasiukevicius | 29 Aug 2009 16:45
Picon

Re: uarea swap-out

Andrew Doran <ad <at> netbsd.org> wrote:
> On Fri, Aug 28, 2009 at 10:59:06PM +0100, Mindaugas Rasiukevicius wrote:
> 
> > http://www.netbsd.org/~rmind/uarea_swapout4.diff
> 
> - Suggest leaving the ps keywords in place and documented.  Removing them
>   could break scripts, and leaving them in serves as a reminder not to reuse
>   the same flag letters in the display.  top and systat are by and large
>   visual so I don't have the same concern about them.  Benfit of removing
>   them is only cosmetic.

Makes sense, but I think ps(1) man page should be updated. We can leave
comments in the source code about re-using of letters.

> - You can probably get rid of XS_CTL_DATA_ONSTACK.
> 

Will do.

> - lwp_t::l_swaplock: worth leaving as a reserved field?
> 

It is a struct, prefer to clean it up.

> - uvmexp_sysctl::swapins, swapouts: would leave these and not rename so you
>   don't break compilation of third party software.  Consider the various X
>   widgets that display graphs and so on.

Reasonable point. For now, I will also leave the members in struct uvmexp,
because vmstat(1) is using it (vmstat should be fixed!).
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Laight | 30 Aug 2009 18:40
Picon

Re: uarea swap-out

On Sat, Aug 29, 2009 at 03:45:07PM +0100, Mindaugas Rasiukevicius wrote:
> 
> Will do.
> 
> > - lwp_t::l_swaplock: worth leaving as a reserved field?
> > 
> 
> It is a struct, prefer to clean it up.

Leaving as a pad avoids breaking binary comparibility.

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |

Gmane