From: Christoph Lameter <christoph@xxxxxxxxxxx> Date: Thu, 23 Jun 2005 20:49:17 -0700 (PDT) > No I told you that we need to disassemble the atomic dec_and_test > in order to be able to split the counters. Ok. You're going to have to come up with something better than a %3 AIM benchmark increase with 5000 threads to justify those invasive NUMA changes, and thus this infrastructure for it. In order to convince me on this NUMA dst stuff, you need to put away the benchmark microscope and instead use a "macroscrope" to analyze the side effects of these changes on a higher level. Really, what are the effects on other things? For example, what does this do to routing performance? Does the packets per second go down, if so by how much? What happens if you bind network interfaces, and the processes that use them, to cpus. Why would that be too intrusive to setup for the administrator of such large NUMA machines? What about loads that have low route locality, and thus touch many different dst entries, not necessarily contending for a single one amongst several nodes? Does performance go up or down for such a case? I'm picking those examples, because I am rather certain your patches will hurt performance in those cases. The data structure size expansion and extra memory allocations alone for the per-node dst stuff should be good about doing that. > > > Yes and it was recently changed. Typical use is linux-xxx@xxxxxxxxxxxxxxx > > > > netdev@xxxxxxxxxxx is what used to be the place for networking > > stuff, it's not netdev@xxxxxxxxxxxxxxx > > s/not/now/ right? Right. :) - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
