On Tue, 30 Aug 2016, Mel Gorman wrote:
> > Userspace mapped pages can be hugepages as well as giant pages and that
> > has been there for a long time. Intermediate sizes would be useful too in
> > order to avoid having to keep lists of 4k pages around and continually
> > scan them.
> >
>
> Userspa
On Thu, Aug 25, 2016 at 02:55:43PM -0500, Christoph Lameter wrote:
> On Thu, 25 Aug 2016, Mel Gorman wrote:
>
> > Flipping the lid aside, there will always be a need for fast management
> > of 4K pages. The primary use case is networking that sometimes uses
> > high-order pages to avoid allocator
On Mon, 29 Aug 2016, Michal Hocko wrote:
> Compaction can certainly help and the more we are proactive in that
> direction the better. Vlastimil has already done a first step in that
> direction and we a have a dedicated kcompactd kernel thread for that
> purpose. But I guess what Mel had in mind
On Fri 26-08-16 13:47:47, Andi Kleen wrote:
> Christoph Lameter writes:
> >
> >> If you want to rework the VM to use a larger fundamental unit, track
> >> sub-units where required and deal with the internal fragmentation issues
> >> then by all means go ahead and deal with it.
> >
> > Hmmm... The
Christoph Lameter writes:
>
>> If you want to rework the VM to use a larger fundamental unit, track
>> sub-units where required and deal with the internal fragmentation issues
>> then by all means go ahead and deal with it.
>
> Hmmm... The time problem is always there. Tried various approaches ove
On Thu, 25 Aug 2016, Mel Gorman wrote:
> Flipping the lid aside, there will always be a need for fast management
> of 4K pages. The primary use case is networking that sometimes uses
> high-order pages to avoid allocator overhead and amortise DMA setup.
> Userspace-mapped pages will always be 4K a
On Thu, 25 Aug 2016, Michal Hocko wrote:
> I can completely see how having multiple allocators (schedulers etc...)
> Because as of now, most users are using whatever is the default (SLUB
> for some and never documented reason) or what their distributions come
> up with. This means that we have quit
On Wed, Aug 24, 2016 at 11:01:43PM -0500, Christoph Lameter wrote:
> On Wed, 24 Aug 2016, Mel Gorman wrote:
> > If/when I get back to the page allocator, the priority would be a bulk
> > API for faster allocs of batches of order-0 pages instead of allocating
> > a large page and splitting.
> >
>
>
On Wed 24-08-16 23:10:03, Christoph Lameter wrote:
> On Tue, 23 Aug 2016, Andi Kleen wrote:
>
> > Why would you stop someone from working on SLAB if they want to?
> >
> > Forcibly enforcing a freeze on something can make sense if you're
> > in charge of a team to conserve resources, but in Linux t
On Wed, 24 Aug 2016, Mel Gorman wrote:
> If/when I get back to the page allocator, the priority would be a bulk
> API for faster allocs of batches of order-0 pages instead of allocating
> a large page and splitting.
>
OMG. Do we really want to continue this? There are billions of Linux
devices out
On Tue, 23 Aug 2016, Andi Kleen wrote:
> Why would you stop someone from working on SLAB if they want to?
>
> Forcibly enforcing a freeze on something can make sense if you're
> in charge of a team to conserve resources, but in Linux the situation is
> very different.
I agree and frankly having m
On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote:
> Do we have any documentation/study about which particular workloads
> benefit from which allocator? It seems that most users will use whatever
> the default or what their distribution uses. E.g. SLES kernel use SLAB
> because this is w
On Wed 24-08-16 10:15:02, Joonsoo Kim wrote:
> On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote:
> > On Tue 23-08-16 11:13:03, Joonsoo Kim wrote:
> > > On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote:
> > [...]
> > > > I am not opposing the patch (to be honest it is quite n
On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote:
> On Tue 23-08-16 11:13:03, Joonsoo Kim wrote:
> > On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote:
> [...]
> > > I am not opposing the patch (to be honest it is quite neat) but this
> > > is buggering me for quite some time
Michal Hocko writes:
>
>> Anyway, we cannot remove one without regression so we don't remove one
>> until now. In this case, there is no point to stop improving one.
>
> I can completely see the reason to not drop SLAB (and I am not suggesting
> that) but I would expect that SLAB would be more in
On Tue 23-08-16 11:13:03, Joonsoo Kim wrote:
> On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote:
[...]
> > I am not opposing the patch (to be honest it is quite neat) but this
> > is buggering me for quite some time. Sorry for hijacking this email
> > thread but I couldn't resist. Why a
16 matches
Mail list logo
