> -----Original Message----- > From: Matthew Wilcox [mailto:matthew@xxxxxx] > Sent: Thursday, May 05, 2011 1:12 AM > To: Desai, Kashyap > Cc: linux-scsi@xxxxxxxxxxxxxxx; James.Bottomley@xxxxxxxxxxxxxxxxxxxxx; > Moore, Eric; Prakash, Sathya > Subject: Re: [PATCH 1/3] mpt2sas: removetheuseofwriteq@xxxxxxx, since > writeq is not atomic > > On Wed, May 04, 2011 at 04:33:51PM +0530, Kashyap, Desai wrote: > > We need the 64 bit completed in one access pci memory write, else > spin lock is required. > > Since it's going to be difficult to know which writeq was implemented > in the kernel, > > the driver is going to have to always acquire a spin lock each time > we do 64bit write. > > */ > > -#ifndef writeq > > static inline void _base_writeq(__u64 b, volatile void __iomem > *addr, > > spinlock_t *writeq_lock) > > { > > @@ -1570,13 +1569,6 @@ static inline void _base_writeq(__u64 b, > volatile void __iomem *addr, > > writel((u32)(data_out >> 32), (addr + 4)); > > spin_unlock_irqrestore(writeq_lock, flags); > > } > > -#else > > -static inline void _base_writeq(__u64 b, volatile void __iomem > *addr, > > - spinlock_t *writeq_lock) > > -{ > > - writeq(cpu_to_le64(b), addr); > > -} > > -#endif > > > > Instead of taking out this optimisation (which is going to hurt > massively > on 8-socket systems), why not simply change: > > -#ifndef writeq > +#if BITS_PER_LONG < 64 > > (OK, there's an assumption that all 64-bit systems have an atomic 64- > bit > MMIO store operation ... but I think that's a valid assumption). For powerpc64 arch " BITS_PER_LONG is defined as 64" and we have seen writeq() is not atomic for that particular case. So question is for all 64 bit arch writeq() must be atomic. > > -- > Matthew Wilcox Intel Open Source Technology Centre > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
