linux-kernel - Re: [patch 1/2] agpgart - allow user-populated memory types.

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:	Sat, 9 Dec 2006 00:05:48 +0100 (CET)
From:	Thomas Hellström <thomas@...gstengraphics.com>
To:	"Arjan van de Ven" <arjan@...radead.org>
Cc:	Thomas Hellström <thomas@...gstengraphics.com>,
	"Dave Jones" <davej@...hat.com>, "Dave Airlie" <airlied@...ux.ie>,
	"Linux Kernel list" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/2] agpgart - allow user-populated memory types.

> On Fri, 2006-12-08 at 19:24 +0100, Thomas HellstrÃ¶m wrote:
>>
>> +       }
>> +
>> +       if (alloc_size <= PAGE_SIZE) {
>> +               new->memory = kmalloc(alloc_size, GFP_KERNEL);
>> +       }
>> +       if (new->memory == NULL) {
>> +               new->memory = vmalloc(alloc_size);
>
> this bit is more or less evil as well...
>
> 1) vmalloc is expensive all the way, higher tlb use etc etc
> 2) mixing allocation types is just a recipe for disaster
> 3) if this isn't a frequent operation, kmalloc is fine upto at least 2
> pages; I doubt you'll ever want more

I understand your feelings about this, and as you probably understand, the
kfree / vfree thingy is a result of the above allocation scheme.

The allocated memory holds an array of struct page pointers. The number of
struct page pointers will range from 1 to about 8192, so the alloc size
will range from 4bytes to 64K, but could go higher depending on
architecture. I figured that kmalloc could fail, and, according to "linux
device drivers" (IIRC), vmalloc is faster when allocation size exceeds 1
page. Using only vmalloc waists far too much memory if the number of small
buffers is high.

So we can't use only vmalloc, and we can't fail so we can't use only
kmalloc. I'm open to suggestions on how to improve this.

Regards,
Thomas

>
>
>
> --
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com
> Test the interaction between Linux and your BIOS via
> http://www.linuxfirmwarekit.org
>
>

-
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/