Re: km_alloc/km_free optimization

2015-01-19 Thread Mark Kettenis
> From: David Gwynne > Date: Mon, 19 Jan 2015 11:53:09 +1000 > > > On 30 Dec 2014, at 22:49, Mark Kettenis wrote: > > > >> From: David Gwynne > >> Date: Tue, 30 Dec 2014 21:53:46 +1000 > >> > >>> On 29 Dec 2014, at 7:55 am, Mark Kettenis wrote: > >>> > Date: Sun, 28 Dec 2014 20:56:33 +

Re: km_alloc/km_free optimization

2015-01-18 Thread David Gwynne
> On 30 Dec 2014, at 22:49, Mark Kettenis wrote: > >> From: David Gwynne >> Date: Tue, 30 Dec 2014 21:53:46 +1000 >> >>> On 29 Dec 2014, at 7:55 am, Mark Kettenis wrote: >>> Date: Sun, 28 Dec 2014 20:56:33 +0100 (CET) From: Mark Kettenis P.S. I would not be surprised if

Re: km_alloc/km_free optimization

2014-12-30 Thread Mark Kettenis
> From: David Gwynne > Date: Tue, 30 Dec 2014 21:53:46 +1000 > > > On 29 Dec 2014, at 7:55 am, Mark Kettenis wrote: > > > >> Date: Sun, 28 Dec 2014 20:56:33 +0100 (CET) > >> From: Mark Kettenis > >> > >> P.S. I would not be surprised if this would "fix" the problems landisk > >> has with

Re: km_alloc/km_free optimization

2014-12-28 Thread Mark Kettenis
> Date: Sun, 28 Dec 2014 20:56:33 +0100 (CET) > From: Mark Kettenis > > P.S. I would not be surprised if this would "fix" the problems landisk > has with the "* 8" pool diff. Currently updating my landisk to > verify. And it seems this does fix the landisk problem. I strongly suspect

km_alloc/km_free optimization

2014-12-28 Thread Mark Kettenis
One side-effect of dlg@'s "* 8" pool diff is that some pools now use "large" pool pages that aren't directly mapped on PMAP_DIRECT architecture. In general it's not possible to map "large" pages directly since the individual memory pages are not guaranteed to be contigious. However, the mbuf clus