LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas@tungstengraphics.com>
To: "Arjan van de Ven" <arjan@infradead.org>
Cc: "Thomas Hellström" <thomas@tungstengraphics.com>,
	"Dave Jones" <davej@redhat.com>, "Dave Airlie" <airlied@linux.ie>,
	"Linux Kernel list" <linux-kernel@vger.kernel.org>
Subject: Re: [patch 1/2] agpgart - allow user-populated memory types.
Date: Sat, 9 Dec 2006 00:05:48 +0100 (CET)	[thread overview]
Message-ID: <1095.213.114.71.166.1165619148.squirrel@www.shipmail.org> (raw)
In-Reply-To: <1165616236.27217.108.camel@laptopd505.fenrus.org>

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



  reply	other threads:[~2006-12-08 23:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 18:24 Thomas Hellström
2006-12-08 22:03 ` Arjan van de Ven
2006-12-08 22:17 ` Arjan van de Ven
2006-12-08 23:05   ` Thomas Hellström [this message]
2006-12-19  8:47     ` Arjan van de Ven
2006-12-19  9:44       ` Thomas Hellström
2006-12-19 12:17         ` Arjan van de Ven
2006-12-19 12:47           ` Thomas Hellström
2006-12-19 13:11             ` Arjan van de Ven
2006-12-19 14:11               ` Thomas Hellström
2007-01-08  9:33               ` agpgart: drm-populated " thomas
2007-01-09  2:37                 ` Arjan van de Ven
2007-01-09  8:28                   ` Thomas Hellström
2007-01-09  8:23                 ` [PATCH] agpgart: Allow drm-populated agp " thomas
2007-01-09 14:05                   ` Arjan van de Ven
2007-01-09 14:06                   ` Arjan van de Ven
2007-01-23  9:33                     ` New patch: drm-populated " thomas
2007-01-23  9:33                       ` [PATCH] agpgart: Allow drm-populated agp " thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1095.213.114.71.166.1165619148.squirrel@www.shipmail.org \
    --to=thomas@tungstengraphics.com \
    --cc=airlied@linux.ie \
    --cc=arjan@infradead.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [patch 1/2] agpgart - allow user-populated memory types.' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).