Date: Fri, 31 Jul 1998 00:26:28 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: bde@zeta.org.au (Bruce Evans) Cc: current@FreeBSD.ORG, luoqi@chen.ml.org Subject: Re: using vm_page.h in userland program Message-ID: <199807310526.AAA26521@dyson.iquest.net> In-Reply-To: <199807300833.SAA05989@godzilla.zeta.org.au> from Bruce Evans at "Jul 30, 98 06:33:38 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans said: > >Recent change (addition of cache coloring) to vm/vm_page.h has made it > >impossible to use this header file in a userland program. It tries to > >include "opt_vmpage.h" unconditionally. IMO, "opt_vmpage.h" should only > >be included when KERNEL is defined. Would someone please make the change? > .... > > > The cache coloring options should be dynamic anyway. I have tried a few > different values on various machines but didn't notice much difference > and didn't have time to do careful comparisons. > The cache coloring tuning itself was on my list, and not really hard to do. It should also have a machine dependent component, and also query the processor, if it can, for info. The work to make the coloring dynamic is just a coding effort. The biggest issue (AFAIR) is that the current code is fairly efficient because of the inline usage of nice, power of two values. By making things dynamic, it is tricky to keep efficiency high. The additional overhead of doing the coloring might make it undesirable. It isn't necessary for the coloring to be "perfect" either, so it is okay to color a 256K cache system as if it is a 512K cache machine. Some coloring algorithms would become less efficient, but the FreeBSD one is okay with it. The coloring scheme that I chose for FreeBSD doesn't have the disadvantage of other, typical algorithms by being inflexible when memory of a certain color isn't available. Note that the micro-level coloring is really good, but the macro-level coloring could use some work. (The choice of the color for each object should be revisited.) Page coloring is awfully hard to benchmark. The only "quick" benchmark that I had was lmbench, lat_mem_rd. Page coloring mostly helps the system avoid "worst case" behavior, but to gain a sustained significant performance improvement is not likely. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807310526.AAA26521>