On 8/9/07, Oliver Yang <Oliver.Yang at sun.com> wrote: > > Jonathan Adams wrote: > > [ snipped...] > > > > Looking at the ::kmem_cache output: > > > > 32-bit: > > >::kmem_cache ! grep streams_dblk_1984 > > cac2e2b0 streams_dblk_1984 020f 000000 2048 9 > > > > 64-bit > > > ::kmem_cache ! grep streams_dblk_1936 > > ffffffffec0033c08 streams_dblk_1936 0269 000000 2048 602 > > > > The third field is the "flags" field; this contains the full reason > > for all the differences you noticed. > > > > 32-bit: KMF_HASH | KMF_CONTENTS | KMF_AUDIT | KMF_DEADBEEF | > KMF_REDZONE > > 64-bit: KMF_HASH | KMF_CONTENTS | KMF_AUDIT | KMF_FIREWALL | > > KMF_NOMAGAZINE > ...elided... > Hi Jonathan, > > I have a question about your comments above: > > Raymond have told me he already set the kmem_flags = 0xf in the system, > why the kmem cache debug flags are still different between 32bit and > 64bit kernel? > > The kmem_flags setting should be effecting for all of cache, right?
They do (and in both cases, kmem_flags was set to 0xf). The issue is that the way kmem_flags gets translated into a particular cache's cache_flags is non-trivial; see http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/kmem.c#2071 Things like firewalling are actually satisfying the intent of the KMF_REDZONE flag (for example), but do so in a way that is incompatible with the code which follows KMF_REDZONE. Cheers, - jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20070809/41e8b4e3/attachment.html>
