Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756967AbaKUAyH (ORCPT ); Thu, 20 Nov 2014 19:54:07 -0500 Received: from www.linutronix.de ([62.245.132.108]:53823 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756223AbaKUAyF (ORCPT ); Thu, 20 Nov 2014 19:54:05 -0500 Date: Fri, 21 Nov 2014 01:54:00 +0100 (CET) From: Thomas Gleixner To: Tejun Heo cc: Frederic Weisbecker , Linus Torvalds , Dave Jones , Don Zickus , Linux Kernel , the arch/x86 maintainers , Peter Zijlstra , Andy Lutomirski , Arnaldo Carvalho de Melo Subject: Re: frequent lockups in 3.18rc4 In-Reply-To: <20141120230514.GB25393@htj.dyndns.org> Message-ID: References: <20141119190215.GA10796@lerouge> <20141119225615.GA11386@lerouge> <20141119235033.GE11386@lerouge> <20141120122339.GA14877@htj.dyndns.org> <20141120221122.GA25393@htj.dyndns.org> <20141120230514.GB25393@htj.dyndns.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tejun, On Thu, 20 Nov 2014, Tejun Heo wrote: > On Thu, Nov 20, 2014 at 11:42:42PM +0100, Thomas Gleixner wrote: > > On Thu, 20 Nov 2014, Tejun Heo wrote: > > > On Thu, Nov 20, 2014 at 10:58:26PM +0100, Thomas Gleixner wrote: > > > > It's completely undocumented behaviour, whether it has been that way > > > > for ever or not. And I agree with Fredric, that it is insane. Actuallu > > > > it's beyond insane, really. > > > > > > This is exactly the same for any address in the vmalloc space. > > > > I know, but I really was not aware of the fact that dynamically > > allocated percpu stuff is vmalloc based and therefor exposed to the > > same issues. > > > > The normal vmalloc space simply does not have the problems which are > > generated by percpu allocations which have no documented access > > restrictions. > > > > You created a special case and that special case is clever but not > > very well thought out considering the use cases of percpu variables > > and the completely undocumented limitations you introduced silently. > > > > Just admit it and dont try to educate me about trivial vmalloc > > properties. > > Why are you always so overly dramatic? This has nothing to do with dramatic. It's a matter of fact that I do not need an education on the basic properties of the vmalloc space. I just refuse to accept that you try to tell me that I should be aware of this: > > > This is exactly the same for any address in the vmalloc space. What I was not aware of and even was not aware of after staring into that code fore quite some time is the fact that the whole percpu business is vmalloc based and therefor exposed to the same limitations as the vmalloc space in general. I'm not a mm expert and without the slightest piece of documentation except for the chunk allocator, which is completely irrelevant in this context, there is not a single word of explanation about the design and the resulting limitations of that in the kernel tree. So, I'm overly dramatic, because I tell you that I'm well aware of the general vmalloc approach, which is btw. well documented? > How is this productive? It's obviously very productive, because I'm AFAICT the first person who did not take your design decisions as granted and sacrosanct. > Sure, this could have been better but I missed it at the beginning > and this is the first time I hear about this issue. So the issues Frederic talked about in that very thread about recursive faults and the need that perf had to emulate percpu stuff in order to work around them have never been communicated to you? I that's the case then that's not your problem, but a serious problem in our overall process. > Shits happen and we fix them. I have no problem with that and I'm not trying to put blame on you. As you might have noticed I spent quite some time to think about a possibile solution and also clearly stated that it's perhaps not solving the issue at hand (while it's not complex to implement) it might be too complex backport. The response I get from you is: > > > That isn't enough tho. What if the percpu allocated pointer gets > > > passed to another CPU without task switching? You'd at least need to > > > send IPIs to all CPUs so that all the active PGDs get updated > > > synchronously. > > > > You obviously did not even take the time to carefully read what I > > wrote: > > > > "Now after that increment the allocation side needs to wait for a > > scheduling cycle on all cpus (we have mechanisms for that)" > > > > That's exactly stating what you claim to be 'not enough'. > > Missed that. Sorry. Apology accepted. > So, for now, all we need is adding nmi check in percpu accessors, > right? s/all we need/all we can do/ I think is the proper technical expression for that. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/