From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Subject: Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit Date: Wed, 3 Jun 2009 23:24:43 -0400 Message-ID: <8bd0f97a0906032024k412ac3a5x1dbf52b74dc1ebbd@mail.gmail.com> References: <1243956140.4229.25.camel@mulgrave.int.hansenpartnership.com> <1244034286.24482.84.camel@pc1117.cambridge.arm.com> <1244045997.21423.303.camel@mulgrave.site> <20090603170925.GA8330@flint.arm.linux.org.uk> <20090603114344.bf852654.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+stl+Ii4xbCl5GZc/ovlGGwm1oMjM/LJHxi3wPtjg+M=; b=XBm7u8EneDUKYaSRcMzDek1UJq5IDZYxMuJcVMtIcmta5Hp5FXRouMM0FHAsSgzaP2 2WPcVqvjs5oqzMhCnL8nw/Ft+Y1mAbJDJ+G2Ok25FaxzcQCRVSKjka+/x0u/XLeII8+Z JJEBNqMt9da1NtYtOP2WU0ql42H6MEGujPbVw= In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: "David VomLehn (dvomlehn)" Cc: Andrew Morton , Russell King , James.Bottomley@hansenpartnership.com, linux-arch@vger.kernel.org, linux-embedded@vger.kernel.org, ksummit-2009-discuss@lists.linux-foundation.org On Wed, Jun 3, 2009 at 23:11, David VomLehn (dvomlehn) wrote: > 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. it would help on the Blackfin architecture. we compile all kernel modules with -mlong-call because of this issue. > 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. what do you do if the alloc fails ? return back to userspace with something like ENOMEM and have it retry with a module that was compiled with -mlong-call ? -mike