RE: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Delaney has a proof-of-concept of an idea of his which was
presented at the last CELF, which is basically to put the kernel and
loadable kernel modules closely enough together that you can avoid the
use of long jumps. He sees a better than 1% improvement in performance,
which we've duplicated using a slightly different approach. This is nice
payback for little work and, though it doesn't help on all processors,
it helps on several.

The problem is: how do you allocate memory with the magical "close to
the kernel" attribute? We have something that adds a new ZONE_KERNEL
(this name has some problems, actually). It seems like a pretty good
solution if you look at zones as conceptually concentric usages, but
with the current zone implementation, each zone must be contiguous. So,
if we're talking about changing what zones are done, I'd like to throw
this into the pot.

> -----Original Message-----
> From: linux-embedded-owner@xxxxxxxxxxxxxxx 
> [mailto:linux-embedded-owner@xxxxxxxxxxxxxxx] On Behalf Of 
> Andrew Morton
> Sent: Wednesday, June 03, 2009 11:44 AM
> To: Russell King
> Cc: James.Bottomley@xxxxxxxxxxxxxxxxxxxxx; 
> linux-arch@xxxxxxxxxxxxxxx; linux-embedded@xxxxxxxxxxxxxxx; 
> ksummit-2009-discuss@xxxxxxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ksummit-2009-discuss] Representing Embedded 
> Architectures at the Kernel Summit
> 
> On Wed, 3 Jun 2009 18:09:25 +0100
> Russell King <rmk@xxxxxxxxxxxxxxxx> wrote:
> 
> > In
> > fact, on ARM the DMA mask is exactly that - it's a 100% 
> proper mask.  It's
> > not a bunch of zeros in the MSB followed by a bunch of ones 
> down to the
> > LSB.  It can be a bunch of ones, a bunch of zeros, followed 
> by a bunch of
> > ones.
> > 
> > The way we occasionally have to deal with this is to trial 
> an allocation,
> > see if the physical address fits, if not free the page and 
> try again with
> > GFP_DMA set.
> 
> A couple of times I've suggested that we have the ability to allocate
> one zone per address bit, so a 32-bit machine with 4k pages would end
> up having 20 zones.  Then, your funny DMA mask can be directly passed
> into the page allocator as a zone mask and voila, I think.
> 
> > There's many stories I've heard on what is supposed to take 
> care of the
> > coherency that I now just close my ears to the problem and chant "it
> > doesn't exist, people aren't seeing it, mainline folk just 
> don't give
> > a damn".  Really.  It is a problem on _some_ ARM devices 
> and has been
> > for several years now, and I've 100% given up caring about it.
> 
> I wasn't even aware that there was an issue here.  Please don't blame
> "mainline folk" for something they weren't told about!
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-embedded" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux