On Fri, 28 Sep 2012, Christoph Lameter wrote: > > The first prototype, SLAM XP1, will be posted in October. I'd simply like > > to avoid reverting this patch down the road and having all of us > > reconsider the topic again when clear alternatives exist that, in my > > opinion, make the code cleaner. > > If you want to make changes to the kernel then you need to justify that at > the time when we can consider your patches and the approach taken. > If I cannot speak up and say where there will be conflicts in the future and ask that Glauber spend more of his time down the road to figure all of this out again, especially when a simple and clean alternative exists, then that seems to result in a big waste of time. Nothing is suffering from taking the alternative here, so please follow the best software engineering practices of allowing an implementation to reserve and ignore bits in an API when appropriate and not do it globally in the common code. All of the move to mm/slab_common.c has obviously slowed down posting of SLAM and I haven't complained about that once or asked that it not be done, I'm simply pointing out an instance here that will conflict later on if we go with this patch. That, to me, is respectful of other people's time. That said, I'll leave it to Glauber to decide how he'd like to handle this issue given the knowledge of what is to come. Thanks. -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>