On Sat 21-04-18 07:47:57, Matthew Wilcox wrote: > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > > On Fri, 20 Apr 2018, Michal Hocko wrote: > > > > > No way. This is just wrong! First of all, you will explode most likely > > > > > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be > > > > > enabled quite often. > > > > > > > > You're an evil person who doesn't want to fix bugs. > > > > > > Steady on. There's no need for that. Michal isn't evil. Please > > > apologise. > > > > I see this attitude from Michal again and again. > > Fine; then *say that*. I also see Michal saying "No" a lot. Sometimes > I agree with him, sometimes I don't. I think he genuinely wants the best > code in the kernel, and saying "No" is part of it. Exactly! We have a lot of legacy herritage and random semantic because we were too eager to merge stuff. I think it is time to stop that and think twice before merging someothing. If you call that evil then I am fine to be evil. > > He didn't want to fix vmalloc(GFP_NOIO) > > I don't remember that conversation, so I don't know whether I agree with > his reasoning or not. But we are supposed to be moving away from GFP_NOIO > towards marking regions with memalloc_noio_save() / restore. If you do > that, you won't need vmalloc(GFP_NOIO). It was basically to detect GFP_NOIO context _inside_ vmalloc and use the scope API to enforce it there. Does it solve potential problems? Yes it does. Does it solve any existing report, no I am not aware of any. Is it a good fix longterm? Absolutely no, because the scope API should be used _at the place_ where the scope starts rather than a random utility function. If we are going the easier way now, we will never teach users to use the API properly. And I am willing to risk to keep a broken code which we have for years rather than allow a random hack that will seemingly fix it. Btw. I was pretty much explicit with this reasoning when rejecting the patch. Do you still call that evil? > > he didn't want to fix alloc_pages sleeping when __GFP_NORETRY is used. > > The GFP flags are a mess, still. I do not remember that one but __GFP_NORETRY is _allowed_ to sleep. And yes I do _agree_ gfp flags are a mess which is really hard to get fixed because they are lacking a good design from the very beginning. Fixing some of those issues today is a completely PITA. > > So what should I say? Fix them and > > you won't be evil :-) > > No, you should reserve calling somebody evil for truly evil things. > > > (he could also fix the oom killer, so that it is triggered when > > free_memory+cache+free_swap goes beyond a threshold and not when you loop > > too long in the allocator) > > ... that also doesn't make somebody evil. And again, it is way much more easier to claim that something will get fixed when the reality is much more complicated. I've tried to explain those risks as well. > > I already said that we can change it from CONFIG_DEBUG_VM to > > CONFIG_DEBUG_SG - or to whatever other option you may want, just to make > > sure that it is enabled in distro debug kernels by default. > > Yes, and I think that's the right idea. So send a v2 and ignore the > replies that are clearly relating to an earlier version of the patch. > Not everybody reads every mail in the thread before responding to one they > find interesting. Yes, ideally, one would, but sometimes one doesn't. And look here. This is yet another ad-hoc idea. We have many users of kvmalloc which have no relation to SG, yet you are going to control their behavior by CONFIG_DEBUG_SG? No way! (yeah evil again) Really, we have a fault injection framework and this sounds like something to hook in there. -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
