public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* cachefs broken on ppc64
@ 2004-11-21 23:24 Paul Mackerras
  2004-11-22 12:01 ` David Howells
  0 siblings, 1 reply; 2+ messages in thread
From: Paul Mackerras @ 2004-11-21 23:24 UTC (permalink / raw)
  To: dhowells; +Cc: linux-kernel, akpm

David,

I just tried compiling 2.6.10-rc2-mm2, and just for fun, I turned on
cachefs, and found out that cachefs won't build on ppc64.  The problem
is that it is using xchg() on 16-bit quantities, which we don't
support on ppc (32 or 64).  Is there a good reason why
cachefs_super.ujnl_serial has to be 16 bits rather than 32?

It worries me a bit that you are using xchg() so much, actually.  It
feels like you are trying to be clever and do things without taking
any locks, but there are no memory barriers anywhere in fs/cachefs
that I could see.  So I suspect it would have problems on SMP ppc64 or
ia64 systems, which have weak memory consistency.  Or is there some
serialization at a higher level that saves you?  (If so, why do you
need to use xchg()?)

Paul.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: cachefs broken on ppc64
  2004-11-21 23:24 cachefs broken on ppc64 Paul Mackerras
@ 2004-11-22 12:01 ` David Howells
  0 siblings, 0 replies; 2+ messages in thread
From: David Howells @ 2004-11-22 12:01 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linux-kernel, akpm


> I just tried compiling 2.6.10-rc2-mm2, and just for fun, I turned on
> cachefs, and found out that cachefs won't build on ppc64.  The problem
> is that it is using xchg() on 16-bit quantities, which we don't
> support on ppc (32 or 64).  Is there a good reason why
> cachefs_super.ujnl_serial has to be 16 bits rather than 32?

Because the on-disc value is 16 bits, I suppose.

Actually, if you are looking at the one in journal.c, that probably doesn't
need the xchg() at all. There's a write-locked rwsem covering the region.

> It worries me a bit that you are using xchg() so much, actually.  It
> feels like you are trying to be clever and do things without taking
> any locks, but there are no memory barriers anywhere in fs/cachefs
> that I could see.

In many of the cases, there're spinlocks or semaphores covering the xchg(), so
those don't really need to be xchg calls, I suppose.

> So I suspect it would have problems on SMP ppc64 or ia64 systems, which have
> weak memory consistency.  Or is there some serialization at a higher level
> that saves you?  (If so, why do you need to use xchg()?)

There is serialisation in the form of spinlocks and semaphores covering many
of the exchanges, but not all. I'm not entirely sure where I need memory
barriers - i386 doesn't really have them.

David

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-11-22 12:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-21 23:24 cachefs broken on ppc64 Paul Mackerras
2004-11-22 12:01 ` David Howells

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox