On Tue, 2014-02-11 at 12:30 -0600, Scott Wood wrote:
> > It's something very special to IBM pSeries: the hypervisor can assign
> > fractions of physical CPUs to guests. Sometimes a guest with 4 quarter
> > CPUs will be faster than 1 monoprocessor. (correct me if I'm wrong).
> >
> > The directed yi
On Tue, 2014-02-11 at 11:40 +0100, Torsten Duwe wrote:
> On Tue, Feb 11, 2014 at 03:23:51PM +0530, Raghavendra KT wrote:
> > How much important to have holder information for PPC? From my
> > previous experiment
> > on x86, it was lock-waiter preemption which is problematic rather than
> > lock-hol
On Tue, Feb 11, 2014 at 03:23:51PM +0530, Raghavendra KT wrote:
> How much important to have holder information for PPC? From my
> previous experiment
> on x86, it was lock-waiter preemption which is problematic rather than
> lock-holder preemption.
It's something very special to IBM pSeries: the
On Mon, Feb 10, 2014 at 8:40 AM, Benjamin Herrenschmidt
wrote:
> On Fri, 2014-02-07 at 17:58 +0100, Torsten Duwe wrote:
>> typedef struct {
>> - volatile unsigned int slock;
>> -} arch_spinlock_t;
>> + union {
>> + __ticketpair_t head_tail;
>> + struct __ra
On Fri, Feb 7, 2014 at 10:28 PM, Torsten Duwe wrote:
> Ticket locks for ppc, version 2. Changes since v1:
> * The atomically exchanged entity is always 32 bits.
> * asm inline string variations thus removed.
> * Carry the additional holder hint only #if defined(CONFIG_PPC_SPLPAR)
>
> Signed-off-by
On Tue, 2014-02-11 at 02:56 +, Al Viro wrote:
> > So the question is, is it reasonable to have the ref smaller than
> > 32-bit...
>
> Every time you open a file, you bump dentry refcount. Something like
> libc or ld.so will be opened on just about every execve(), so I'd say
> that 16 bits is
On Tue, Feb 11, 2014 at 01:44:20PM +1100, Benjamin Herrenschmidt wrote:
> That leaves us with 32 bits to put the ref and the owner. The question
> is how big the ref really has to be and can we have a reasonable failure
> mode if it overflows ?
>
> If we limit ourselves to, for example, 16-bit for
(Linus, Al, a question for you down there about lockref "ref" size)
On Mon, 2014-02-10 at 16:52 +0100, Torsten Duwe wrote:
> What if I squeeze the bits a little?
> 4k vCPUs, and 256 physical, as a limit to stay within 32 bits?
> At the cost that unlock may become an ll/sc operation again.
> I cou
On Mon, Feb 10, 2014 at 04:52:17PM +0100, Torsten Duwe wrote:
> Opinions, anyone?
Since the holder thing is a performance thing, not a correctness thing;
one thing you could do is something like:
static const int OWNER_HASH_SIZE = CONFIG_NR_CPUS * 4;
static const int OWNER_HASH_BITS = ilog2(OWNER
On Mon, Feb 10, 2014 at 02:10:23PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-02-07 at 17:58 +0100, Torsten Duwe wrote:
> > typedef struct {
> > - volatile unsigned int slock;
> > -} arch_spinlock_t;
> > + union {
> > + __ticketpair_t head_tail;
> > +
On Fri, 2014-02-07 at 17:58 +0100, Torsten Duwe wrote:
> typedef struct {
> - volatile unsigned int slock;
> -} arch_spinlock_t;
> + union {
> + __ticketpair_t head_tail;
> + struct __raw_tickets {
> +#ifdef __BIG_ENDIAN__ /* The "tail" part should
On Fri, Feb 07, 2014 at 06:12:24PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 05:58:01PM +0100, Torsten Duwe wrote:
> > +static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
> > {
> > + register struct __raw_tickets old, tmp,
> > + inc = { .tail = TICKET_LOCK_I
On Fri, Feb 07, 2014 at 05:58:01PM +0100, Torsten Duwe wrote:
> +static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
> {
> + register struct __raw_tickets old, tmp,
> + inc = { .tail = TICKET_LOCK_INC };
> +
> CLEAR_IO_SYNC;
> + __asm__ __volatile__(
> +"1:
Ticket locks for ppc, version 2. Changes since v1:
* The atomically exchanged entity is always 32 bits.
* asm inline string variations thus removed.
* Carry the additional holder hint only #if defined(CONFIG_PPC_SPLPAR)
Signed-off-by: Torsten Duwe
--
arch/powerpc/include/asm/spinlock_types.h |
14 matches
Mail list logo
