From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [Patch V3 0/3] Enable irqs when waiting for rwlocks Date: Wed, 03 Dec 2008 13:44:49 +0100 Message-ID: <1228308289.9673.237.camel@twins> References: <20081104122405.046233722@attica.americas.sgi.com> <20081202161311.ae3376cb.akpm@linux-foundation.org> <20081203113744.GE8970@sgi.com> <1228307117.9673.232.camel@twins> <1228307798.1009.1.camel@nathan.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1228307798.1009.1.camel@nathan.suse.cz> Sender: linux-ia64-owner@vger.kernel.org To: Petr Tesarik Cc: Robin Holt , Andrew Morton , linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, tee@sgi.com, mingo@elte.hu, linux-arch@vger.kernel.org List-Id: linux-arch.vger.kernel.org On Wed, 2008-12-03 at 13:36 +0100, Petr Tesarik wrote: > Peter Zijlstra p=C3=AD=C5=A1e v St 03. 12. 2008 v 13:25 +0100: > > On Wed, 2008-12-03 at 05:37 -0600, Robin Holt wrote: > > > > It's a bit regrettable to have different architectures behaving= in > > > > different ways. It would be interesting to toss an x86_64 > > > > implementation into the grinder, see if it causes any problems,= see if > > > > it produces any tangible benefits. Then other architectures mi= ght > > > > follow. Or not, depending on the results ;) > > >=20 > > > I personally expect SGI to work on this for x86_64 in the future. > > > Once we actually start testing systems with 128 and above cpus, I > > > would expect to see these performance issues needing to be addres= sed. > > > Until then, it is just a theoretical. > >=20 > > Personally I consider this a ugly hack and would love to see people > > solve the actual problem and move away from rwlock_t, its utter rub= bish. >=20 > Me too, but we don't have that clean and nice solution today, but wha= t > we _do_ have today are the machines which break badly when interrupts > are disabled for the whole duration of taking a rwlock_t. :( Right, which creates an incentive to work on it. So we then either to a quick and ugly hack and relieve the stress and never again get around t= o looking at that particular issue (because management or something doesn't see the problem anymore) or we do the right thing and fix it properly. I prefer the second, but I understand its not always an option. > Feel free to rewrite all users of rwlock_t. I'll appreciate it, oh so > very much. Hehe, I wish! its on my todo list though, along with some other things, but very unlikely I'll ever get around to it. The good news is that Eric Dumazet recently got rid of a few prominent users in the net code. -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([18.85.46.34]:57899 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbYLCMpA convert rfc822-to-8bit (ORCPT ); Wed, 3 Dec 2008 07:45:00 -0500 Subject: Re: [Patch V3 0/3] Enable irqs when waiting for rwlocks From: Peter Zijlstra In-Reply-To: <1228307798.1009.1.camel@nathan.suse.cz> References: <20081104122405.046233722@attica.americas.sgi.com> <20081202161311.ae3376cb.akpm@linux-foundation.org> <20081203113744.GE8970@sgi.com> <1228307117.9673.232.camel@twins> <1228307798.1009.1.camel@nathan.suse.cz> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Wed, 03 Dec 2008 13:44:49 +0100 Message-ID: <1228308289.9673.237.camel@twins> Mime-Version: 1.0 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Petr Tesarik Cc: Robin Holt , Andrew Morton , linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, tee@sgi.com, mingo@elte.hu, linux-arch@vger.kernel.org Message-ID: <20081203124449.KjnqYKv6YHbPx_rFJ9p_U6aC-Ex5BzpYbMHd6_Y1ulk@z> On Wed, 2008-12-03 at 13:36 +0100, Petr Tesarik wrote: > Peter Zijlstra píše v St 03. 12. 2008 v 13:25 +0100: > > On Wed, 2008-12-03 at 05:37 -0600, Robin Holt wrote: > > > > It's a bit regrettable to have different architectures behaving in > > > > different ways. It would be interesting to toss an x86_64 > > > > implementation into the grinder, see if it causes any problems, see if > > > > it produces any tangible benefits. Then other architectures might > > > > follow. Or not, depending on the results ;) > > > > > > I personally expect SGI to work on this for x86_64 in the future. > > > Once we actually start testing systems with 128 and above cpus, I > > > would expect to see these performance issues needing to be addressed. > > > Until then, it is just a theoretical. > > > > Personally I consider this a ugly hack and would love to see people > > solve the actual problem and move away from rwlock_t, its utter rubbish. > > Me too, but we don't have that clean and nice solution today, but what > we _do_ have today are the machines which break badly when interrupts > are disabled for the whole duration of taking a rwlock_t. :( Right, which creates an incentive to work on it. So we then either to a quick and ugly hack and relieve the stress and never again get around to looking at that particular issue (because management or something doesn't see the problem anymore) or we do the right thing and fix it properly. I prefer the second, but I understand its not always an option. > Feel free to rewrite all users of rwlock_t. I'll appreciate it, oh so > very much. Hehe, I wish! its on my todo list though, along with some other things, but very unlikely I'll ever get around to it. The good news is that Eric Dumazet recently got rid of a few prominent users in the net code.