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