On Tue 18-10-17 10:42:34, Luis Felipe Sandoval Castro wrote: Sorry for the delayed replay, from your feedback I don't think my patch has any chances of being merged... I'm wondering though, if a note in the man pages "range non inclusive" or something like that would help to avoid confusions? Thanks > On Thu 12-10-17 08:28:25, Andi Kleen wrote: > > On Thu, Oct 12, 2017 at 10:46:33AM +0200, Michal Hocko wrote: > > > [CC Christoph who seems to be the author of the code] > > > > Actually you can blame me. I did the mistake originally. > > It was found many years ago, but then it was already too late > > to change. > > > > > Andi has voiced a concern about backward compatibility but I am not > sure > > > the risk is very high. The current behavior is simply broken unless you > > > use a large maxnode anyway. What kind of breakage would you envision > > > Andi? > > > > libnuma uses the available number of nodes as max. > > > > So it would always lose the last one with your chance. > > I must be missing something because libnuma does > if (set_mempolicy(policy, bmp->maskp, bmp->size + 1) < 0) > > so it sets max as size + 1 which is exactly what the man page describes. > > > Your change would be catastrophic. > > I am not sure which change do you mean here. I wasn't proposing any > patch (yet). All I was saying is that the docuementation diagrees with > the in kernel implementation. The only applications that would break > would be those which do not comply to the documentation AFAICS, no? > -- > Michal Hocko > SUSE Labs Best Regards, Luis -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
