linux-kernel - Re: [PATCH 4/4] fdtable: Implement new pagesize-based fdtable allocation scheme.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Oct 2006 10:04:13 -0700
From:	Vadim Lobanov <vlobanov@...akeasy.net>
To:	Andi Kleen <ak@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] fdtable: Implement new pagesize-based fdtable allocation scheme.

On Monday 02 October 2006 03:01, Andi Kleen wrote:
> Vadim Lobanov <vlobanov@...akeasy.net> writes:
> > The allocation algorithm sizes the fdarray in such a way that its memory
> > usage increases in easy page-sized chunks. Additionally, it tries to
> > account for the optimal usage of the allocators involved: kmalloc() for
> > sizes less than a page, and vmalloc() with page granularity for sizes
> > greater than a page.
>
> Best would be to avoid vmalloc() completely because it can be quite
> costly

It's possible. This switch between kmalloc() and vmalloc() was there in the 
original code, and I didn't feel safe ripping it out right now. We can always 
explore this approach too, however.

What is the origin and history of this particular code? (It's been there since 
at least 2.4.x.) Who put in the switch between the two allocators, and for 
what reason? Is that reason still valid?

> -Andi

Thanks for the input.

-- Vadim Lobanov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/