All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Paul Mackerras <paulus@samba.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Andi Kleen <ak@suse.de>,
	Martin Mares <mj@atrey.karlin.mff.cuni.cz>,
	bjornw@axis.com, schwidefsky@de.ibm.com,
	benedict.gaster@superh.com, lethal@linux-sh.org,
	Chris Zankel <chris@zankel.net>,
	Marc Gauthier <marc@tensilica.com>,
	Joe Taylor <joe@tensilica.com>,
	David Mosberger-Tang <davidm@hpl.hp.com>,
	rth@twiddle.net, spyro@f2s.com, starvik@axis.com,
	tony.luck@intel.com, linux-ia64@vger.kernel.org,
	ralf@linux-mips.org, linux-mips@linux-mips.org,
	grundler@parisc-linux.org, parisc-linux@parisc-linux.org,
	linuxppc-dev@ozlabs.org, linux390@de.ibm.com,
	davem@davemloft.net, rusty@rustcorp.com.au
Subject: Re: [PATCH 00/05] robust per_cpu allocation for modules
Date: Mon, 17 Apr 2006 02:07:23 +0000	[thread overview]
Message-ID: <200604170407.26111.arnd@arndb.de> (raw)
In-Reply-To: <1145234750.27828.8.camel@localhost.localdomain>

Am Monday 17 April 2006 02:45 schrieb Steven Rostedt:
> > - does not work in real mode, so percpu data can't be used
> >   inside exception handlers on some architectures.
>
> This is probably a big issue.  I believe interrupt context in hrtimers
> uses per_cpu variables.

If it's just about hrtimers, it should be harmless, since they
are run in softirq context. Even regular interrupt handlers are
always called with paging enabled, otherwise you could not
have them im modules.

> > - memory consumption is rather high when PAGE_SIZE is large
>
> That's also something that I'm trying to solve.  To use the least amount
> of memory and still have the performance.
>
> Now, I've also thought about allocating per_cpu and when a module is
> loaded, reallocate more memory and copy it again.  Use something like
> the kstopmachine to sync the system so that the CPUS don't update any
> per_cpu variables while this is happening, so that things can't get out
> of sync.

I guess this breaks if someone holds a pointer to a per-cpu variable
while a module gets loaded.

	Arnd <><

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Paul Mackerras <paulus@samba.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Andi Kleen <ak@suse.de>,
	Martin Mares <mj@atrey.karlin.mff.cuni.cz>,
	bjornw@axis.com, schwidefsky@de.ibm.com,
	benedict.gaster@superh.com, lethal@linux-sh.org,
	Chris Zankel <chris@zankel.net>,
	Marc Gauthier <marc@tensilica.com>,
	Joe Taylor <joe@tensilica.com>,
	David Mosberger-Tang <davidm@hpl.hp.com>,
	rth@twiddle.net, spyro@f2s.com, starvik@axis.com,
	tony.luck@intel.com, linux-ia64@vger.kernel.org,
	ralf@linux-mips.org, linux-mips@linux-mips.org,
	grundler@parisc-linux.org, parisc-linux@parisc-linux.org,
	linuxppc-dev@ozlabs.org, linux390@de.ibm.com,
	davem@davemloft.net, rusty@rustcorp.com.au
Subject: Re: [PATCH 00/05] robust per_cpu allocation for modules
Date: Mon, 17 Apr 2006 04:07:23 +0200	[thread overview]
Message-ID: <200604170407.26111.arnd@arndb.de> (raw)
In-Reply-To: <1145234750.27828.8.camel@localhost.localdomain>

Am Monday 17 April 2006 02:45 schrieb Steven Rostedt:
> > - does not work in real mode, so percpu data can't be used
> >   inside exception handlers on some architectures.
>
> This is probably a big issue.  I believe interrupt context in hrtimers
> uses per_cpu variables.

If it's just about hrtimers, it should be harmless, since they
are run in softirq context. Even regular interrupt handlers are
always called with paging enabled, otherwise you could not
have them im modules.

> > - memory consumption is rather high when PAGE_SIZE is large
>
> That's also something that I'm trying to solve.  To use the least amount
> of memory and still have the performance.
>
> Now, I've also thought about allocating per_cpu and when a module is
> loaded, reallocate more memory and copy it again.  Use something like
> the kstopmachine to sync the system so that the CPUS don't update any
> per_cpu variables while this is happening, so that things can't get out
> of sync.

I guess this breaks if someone holds a pointer to a per-cpu variable
while a module gets loaded.

	Arnd <><

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-mips@linux-mips.org,
	David Mosberger-Tang <davidm@hpl.hp.com>,
	linux-ia64@vger.kernel.org,
	Martin Mares <mj@atrey.karlin.mff.cuni.cz>,
	spyro@f2s.com, Joe Taylor <joe@tensilica.com>,
	Andi Kleen <ak@suse.de>,
	linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
	benedict.gaster@superh.com, bjornw@axis.com,
	Ingo Molnar <mingo@elte.hu>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	grundler@parisc-linux.org, rusty@rustcorp.com.au,
	starvik@axis.com, Linus Torvalds <torvalds@osdl.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	rth@twiddle.net, Chris Zankel <chris@zankel.net>,
	tony.luck@intel.com, LKML <linux-kernel@vger.kernel.org>,
	ralf@linux-mips.org, Marc Gauthier <marc@tensilica.com>,
	lethal@linux-sh.org, schwidefsky@de.ibm.com, linux390@de.ibm.com,
	davem@davemloft.net, parisc-linux@parisc-linux.org
Subject: Re: [PATCH 00/05] robust per_cpu allocation for modules
Date: Mon, 17 Apr 2006 04:07:23 +0200	[thread overview]
Message-ID: <200604170407.26111.arnd@arndb.de> (raw)
In-Reply-To: <1145234750.27828.8.camel@localhost.localdomain>

Am Monday 17 April 2006 02:45 schrieb Steven Rostedt:
> > - does not work in real mode, so percpu data can't be used
> > =C2=A0 inside exception handlers on some architectures.
>
> This is probably a big issue. =C2=A0I believe interrupt context in hrtime=
rs
> uses per_cpu variables.

If it's just about hrtimers, it should be harmless, since they
are run in softirq context. Even regular interrupt handlers are
always called with paging enabled, otherwise you could not
have them im modules.

> > - memory consumption is rather high when PAGE_SIZE is large
>
> That's also something that I'm trying to solve. =C2=A0To use the least am=
ount
> of memory and still have the performance.
>
> Now, I've also thought about allocating per_cpu and when a module is
> loaded, reallocate more memory and copy it again. =C2=A0Use something like
> the kstopmachine to sync the system so that the CPUS don't update any
> per_cpu variables while this is happening, so that things can't get out
> of sync.

I guess this breaks if someone holds a pointer to a per-cpu variable
while a module gets loaded.

	Arnd <><

  reply	other threads:[~2006-04-17  2:07 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-14 21:18 [PATCH 00/05] robust per_cpu allocation for modules Steven Rostedt
2006-04-14 21:18 ` Steven Rostedt
2006-04-14 21:18 ` Steven Rostedt
2006-04-14 21:18 ` Steven Rostedt
2006-04-14 22:06 ` Andrew Morton
2006-04-14 22:06   ` Andrew Morton
2006-04-14 22:06   ` Andrew Morton
2006-04-14 22:12   ` Steven Rostedt
2006-04-14 22:12     ` Steven Rostedt
2006-04-14 22:12     ` Steven Rostedt
2006-04-14 22:12 ` Chen, Kenneth W
2006-04-14 22:12   ` Chen, Kenneth W
2006-04-14 22:12   ` Chen, Kenneth W
2006-04-14 22:12   ` Chen, Kenneth W
2006-04-14 22:19   ` Steven Rostedt
2006-04-15  3:10 ` [PATCH 00/08] robust per_cpu allocation for modules - V2 Steven Rostedt
2006-04-15  3:10   ` Steven Rostedt
2006-04-15  3:10   ` Steven Rostedt
2006-04-15  5:32 ` [PATCH 00/05] robust per_cpu allocation for modules Nick Piggin
2006-04-15  5:32   ` Nick Piggin
2006-04-15  5:32   ` Nick Piggin
2006-04-15 20:17   ` Steven Rostedt
2006-04-15 20:17     ` Steven Rostedt
2006-04-15 20:17     ` Steven Rostedt
2006-04-16  2:47     ` Nick Piggin
2006-04-16  2:47       ` Nick Piggin
2006-04-16  2:47       ` Nick Piggin
2006-04-16  3:53       ` Steven Rostedt
2006-04-16  3:53         ` Steven Rostedt
2006-04-16  3:53         ` Steven Rostedt
2006-04-16  7:02         ` Paul Mackerras
2006-04-16  7:02           ` Paul Mackerras
2006-04-16  7:02           ` Paul Mackerras
2006-04-16 13:40           ` Steven Rostedt
2006-04-16 13:40             ` Steven Rostedt
2006-04-16 13:40             ` Steven Rostedt
2006-04-16 13:40             ` Steven Rostedt
2006-04-16 14:03             ` Sam Ravnborg
2006-04-16 14:03               ` Sam Ravnborg
2006-04-16 14:03               ` Sam Ravnborg
2006-04-16 15:34             ` Arnd Bergmann
2006-04-16 15:34               ` Arnd Bergmann
2006-04-16 15:34               ` Arnd Bergmann
2006-04-16 18:03               ` Tony Luck
2006-04-16 18:03                 ` Tony Luck
2006-04-16 18:03                 ` Tony Luck
2006-04-17  0:45               ` Steven Rostedt
2006-04-17  0:45                 ` Steven Rostedt
2006-04-17  0:45                 ` Steven Rostedt
2006-04-17  2:07                 ` Arnd Bergmann [this message]
2006-04-17  2:07                   ` Arnd Bergmann
2006-04-17  2:07                   ` Arnd Bergmann
2006-04-17  2:17                   ` Steven Rostedt
2006-04-17  2:17                     ` Steven Rostedt
2006-04-17  2:17                     ` Steven Rostedt
2006-04-17 20:06               ` Ravikiran G Thirumalai
2006-04-17 20:06                 ` Ravikiran G Thirumalai
2006-04-17 20:06                 ` Ravikiran G Thirumalai
2006-04-17  6:47             ` Rusty Russell
2006-04-17  6:47               ` Rusty Russell
2006-04-17  6:47               ` Rusty Russell
2006-04-17 11:33               ` Steven Rostedt
2006-04-17 11:33                 ` Steven Rostedt
2006-04-17 11:33                 ` Steven Rostedt
2006-04-16  7:06         ` Nick Piggin
2006-04-16  7:06           ` Nick Piggin
2006-04-16  7:06           ` Nick Piggin
2006-04-16 16:06           ` Steven Rostedt
2006-04-16 16:06             ` Steven Rostedt
2006-04-16 16:06             ` Steven Rostedt
2006-04-17 17:10           ` Andi Kleen
2006-04-17 17:10             ` Andi Kleen
2006-04-17 17:10             ` Andi Kleen
2006-04-17 16:55   ` Christoph Lameter
2006-04-17 16:55     ` Christoph Lameter
2006-04-17 16:55     ` Christoph Lameter
2006-04-17 22:02     ` Ravikiran G Thirumalai
2006-04-17 22:02       ` Ravikiran G Thirumalai
2006-04-17 22:02       ` Ravikiran G Thirumalai
2006-04-17 23:44       ` Steven Rostedt
2006-04-17 23:44         ` Steven Rostedt
2006-04-17 23:44         ` Steven Rostedt
2006-04-17 23:48         ` Christoph Lameter
2006-04-17 23:48           ` Christoph Lameter
2006-04-17 23:48           ` Christoph Lameter
2006-04-18  1:51           ` Steven Rostedt
2006-04-18  1:51             ` Steven Rostedt
2006-04-18  1:51             ` Steven Rostedt
2006-04-18  6:42         ` Nick Piggin
2006-04-18  6:42           ` Nick Piggin
2006-04-18  6:42           ` Nick Piggin
2006-04-18 12:47           ` Steven Rostedt
2006-04-18 12:47             ` Steven Rostedt
2006-04-18 12:47             ` Steven Rostedt
2006-04-16  6:35 ` Paul Mackerras
2006-04-16  6:35   ` Paul Mackerras
2006-04-16  6:35   ` Paul Mackerras

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=200604170407.26111.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=benedict.gaster@superh.com \
    --cc=bjornw@axis.com \
    --cc=chris@zankel.net \
    --cc=davem@davemloft.net \
    --cc=davidm@hpl.hp.com \
    --cc=grundler@parisc-linux.org \
    --cc=joe@tensilica.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux390@de.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=marc@tensilica.com \
    --cc=mingo@elte.hu \
    --cc=mj@atrey.karlin.mff.cuni.cz \
    --cc=nickpiggin@yahoo.com.au \
    --cc=parisc-linux@parisc-linux.org \
    --cc=paulus@samba.org \
    --cc=ralf@linux-mips.org \
    --cc=rostedt@goodmis.org \
    --cc=rth@twiddle.net \
    --cc=rusty@rustcorp.com.au \
    --cc=schwidefsky@de.ibm.com \
    --cc=spyro@f2s.com \
    --cc=starvik@axis.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.