Messages in this thread | | | Date | Tue, 8 Feb 2005 12:27:58 -0800 | From | Andrew Morton <> | Subject | Re: prezeroing V6 [2/3]: ScrubD |
| |
Christoph Lameter <clameter@sgi.com> wrote: > > On Mon, 7 Feb 2005, Andrew Morton wrote: > > > > No its a page fault benchmark. Dave Miller has done some kernel compiles > > > and I have some benchmarks here that I never posted because they do not > > > show any material change as far as I can see. I will be posting that soon > > > when this is complete (also need to do the same for the atomic page fault > > > ops and the prefaulting patch). > > > > OK, thanks. That's important work. After all, this patch is a performance > > optimisation. > > Well its a bit complicated due to the various configuration. UP, and then > more and more processors. Plus the NUMA stuff and the standard benchmarks > that are basically not suited for SMP tests make this a bit difficult.
The patch is supposed to speed the kernel up with at least some workloads. We 100% need to see testing results with some such workloads to verify that the patch is desirable.
We also need to try to identify workloads whcih might experience a regression and test them too. It isn't very hard.
> > > memory node is bound to a set of cpus. This may be controlled by the > > > NUMA node configuration. F.e. for nodes without cpus. > > > > kthread_bind() should be able to do this. From a quick read it appears to > > have shortcomings in this department (it expects to be bound to a single > > CPU). > > Sorry but I still do not get what the problem is? kscrubd does exactly > what kswapd does and can be handled in the same way. It works fine here > on various multi node configurations and correctly gets CPUs assigned.
We now have a standard API for starting, binding and stopping kernel threads. It's best to use it. - 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/
| |