From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Matt Sealey <matt@genesi-usa.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Linux ARM Kernel ML <linux-arm-kernel@lists.infradead.org>,
devel <devel@driverdev.osuosl.org>,
LKML <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
Seth Jennings <sjenning@linux.vnet.ibm.com>
Subject: Re: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM
Date: Mon, 21 Jan 2013 16:29:41 +0000 [thread overview]
Message-ID: <20130121162941.GT23505@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAKGA1b=whdh9=ke0efUXnJdT-op=7G1uVh82=3OxT5GoHhWvdA@mail.gmail.com>
On Mon, Jan 21, 2013 at 10:20:38AM -0600, Matt Sealey wrote:
> See previous mail to Minchan; local_tlb_flush_kernel_range calls
> cpu_tlb.flush_kernel_range on SMP, but a direct function call
> ("glue(_TLB, flush_kernel_range)" which resolves to
> v7wbi_flush_kernel_range etc. etc.) without CONFIG_SMP.
Actually, that's wrong - it's got nothing to do with SMP vs non-SMP.
It's more to do with which CPUs are being supported. If they all use one
single cache maintanence implementation, then direct calls are used as an
optimization. If they require more than one cache maintanence
implementation, they are indirect calls. SMP really doesn't come into
that decision.
So:
> >> diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
> >> b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> index 09a9d35..ecf75fb 100644
> > > --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> >> +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> @@ -228,7 +228,7 @@ struct zs_pool {
> >> * mapping rather than copying
> >> * for object mapping.
> >> */
> >> -#if defined(CONFIG_ARM)
> >> +#if defined(CONFIG_ARM) && defined(CONFIG_SMP)
Would be wrong.
prev parent reply other threads:[~2013-01-21 16:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 20:24 Matt Sealey
2013-01-18 21:08 ` Russell King - ARM Linux
2013-01-18 21:45 ` Greg Kroah-Hartman
2013-01-19 4:37 ` Konrad Rzeszutek Wilk
2013-01-21 15:24 ` Russell King - ARM Linux
2013-01-22 20:33 ` Konrad Rzeszutek Wilk
2013-01-19 1:11 ` Matt Sealey
2013-01-19 4:46 ` Konrad Rzeszutek Wilk
2013-01-21 5:55 ` Minchan Kim
2013-01-21 16:00 ` Matt Sealey
2013-01-22 15:48 ` Minchan Kim
2013-01-22 20:34 ` Konrad Rzeszutek Wilk
2013-01-21 16:20 ` Matt Sealey
2013-01-21 16:29 ` Russell King - ARM Linux [this message]
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=20130121162941.GT23505@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@genesi-usa.com \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sjenning@linux.vnet.ibm.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®