On Mon, 2007-09-24 at 12:42 -0700, Andrew Morton wrote:
> On Mon, 24 Sep 2007 12:28:11 -0700
> Dave Hansen <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-09-24 at 18:54 +0100, Christoph Hellwig wrote:
> > > As we already say in various messages the percpu counters in here
> > > look rather fishy.
On Mon, 2007-09-24 at 12:42 -0700, Andrew Morton wrote:
On Mon, 24 Sep 2007 12:28:11 -0700
Dave Hansen [EMAIL PROTECTED] wrote:
On Mon, 2007-09-24 at 18:54 +0100, Christoph Hellwig wrote:
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment
On Mon, 2007-09-24 at 16:15 -0700, Andrew Morton wrote:
> On Mon, 24 Sep 2007 16:05:37 -0700
> Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
> > > hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
> > > the kernel has
On Mon, 2007-09-24 at 16:15 -0700, Andrew Morton wrote:
On Mon, 24 Sep 2007 16:05:37 -0700
Dave Hansen [EMAIL PROTECTED] wrote:
On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
the kernel has decided that
On Mon, 24 Sep 2007 16:05:37 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
> > hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
> > the kernel has decided that this machine can possibly have eight CPUs.
> >
> > It's
On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
> hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
> the kernel has decided that this machine can possibly have eight CPUs.
>
> It's an old super-micro board, doesn't have ACPI.
Well, it's looking like we only set
On Mon, 24 Sep 2007 15:06:42 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-09-23 at 23:17 -0700, Andrew Morton wrote:
> > It look like a false positive to me, but really, for a patchset of this
> > complexity and maturity I cannot fathom how it could have escaped any
> > lockdep
On Sun, 2007-09-23 at 23:17 -0700, Andrew Morton wrote:
> It look like a false positive to me, but really, for a patchset of this
> complexity and maturity I cannot fathom how it could have escaped any
> lockdep testing.
I test with lockdep all the time. The problem was that lockdep doesn't
On Mon, 24 Sep 2007 12:28:11 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-09-24 at 18:54 +0100, Christoph Hellwig wrote:
> > As we already say in various messages the percpu counters in here
> > look rather fishy. I'd recomment to take a look at the per-cpu
> > superblock counters
On Mon, 2007-09-24 at 18:54 +0100, Christoph Hellwig wrote:
> As we already say in various messages the percpu counters in here
> look rather fishy. I'd recomment to take a look at the per-cpu
> superblock counters in XFS as they've been debugged quite well
> now and could probably be lifted into
On Mon, Sep 24, 2007 at 12:10:35PM -0700, Andrew Morton wrote:
> > As we already say in various messages the percpu counters in here
> > look rather fishy. I'd recomment to take a look at the per-cpu
> > superblock counters in XFS as they've been debugged quite well
> > now and could probably be
On Mon, 24 Sep 2007 18:54:11 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> As we already say in various messages the percpu counters in here
> look rather fishy. I'd recomment to take a look at the per-cpu
> superblock counters in XFS as they've been debugged quite well
> now and could
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment to take a look at the per-cpu
superblock counters in XFS as they've been debugged quite well
now and could probably be lifted into a generic library for this
kind of think. The code is mostly in
> It look like a false positive to me, but really, for a patchset of
> this complexity and maturity I cannot fathom how it could have
> escaped any lockdep testing.
the code tries to implement per cpu spinlocks, or rather it tries
to bring back the brlocks from way past cute.
we can educate
On Thu, 20 Sep 2007 12:53:20 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote:
> This is the real meat of the entire series. It actually
> implements the tracking of the number of writers to a mount.
> However, it causes scalability problems because there can
> be hundreds of cpus doing
On Thu, 20 Sep 2007 12:53:20 -0700 Dave Hansen [EMAIL PROTECTED] wrote:
This is the real meat of the entire series. It actually
implements the tracking of the number of writers to a mount.
However, it causes scalability problems because there can
be hundreds of cpus doing open()/close() on
It look like a false positive to me, but really, for a patchset of
this complexity and maturity I cannot fathom how it could have
escaped any lockdep testing.
the code tries to implement per cpu spinlocks, or rather it tries
to bring back the brlocks from way past cute.
we can educate
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment to take a look at the per-cpu
superblock counters in XFS as they've been debugged quite well
now and could probably be lifted into a generic library for this
kind of think. The code is mostly in
On Mon, 24 Sep 2007 18:54:11 +0100
Christoph Hellwig [EMAIL PROTECTED] wrote:
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment to take a look at the per-cpu
superblock counters in XFS as they've been debugged quite well
now and could probably
On Mon, Sep 24, 2007 at 12:10:35PM -0700, Andrew Morton wrote:
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment to take a look at the per-cpu
superblock counters in XFS as they've been debugged quite well
now and could probably be lifted
On Mon, 24 Sep 2007 12:28:11 -0700
Dave Hansen [EMAIL PROTECTED] wrote:
On Mon, 2007-09-24 at 18:54 +0100, Christoph Hellwig wrote:
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment to take a look at the per-cpu
superblock counters in XFS
On Mon, 2007-09-24 at 18:54 +0100, Christoph Hellwig wrote:
As we already say in various messages the percpu counters in here
look rather fishy. I'd recomment to take a look at the per-cpu
superblock counters in XFS as they've been debugged quite well
now and could probably be lifted into a
On Sun, 2007-09-23 at 23:17 -0700, Andrew Morton wrote:
It look like a false positive to me, but really, for a patchset of this
complexity and maturity I cannot fathom how it could have escaped any
lockdep testing.
I test with lockdep all the time. The problem was that lockdep doesn't
On Mon, 24 Sep 2007 15:06:42 -0700
Dave Hansen [EMAIL PROTECTED] wrote:
On Sun, 2007-09-23 at 23:17 -0700, Andrew Morton wrote:
It look like a false positive to me, but really, for a patchset of this
complexity and maturity I cannot fathom how it could have escaped any
lockdep testing.
On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
the kernel has decided that this machine can possibly have eight CPUs.
It's an old super-micro board, doesn't have ACPI.
Well, it's looking like we only set
On Mon, 24 Sep 2007 16:05:37 -0700
Dave Hansen [EMAIL PROTECTED] wrote:
On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
hm. I saw that warning on my 2-way. It has CONFIG_NR_CPUS=8 so perhaps
the kernel has decided that this machine can possibly have eight CPUs.
It's an old
26 matches
Mail list logo
