[mdb-discuss] ::kmastat output different in meaning between x86 32-bit and 64-bit?

2007-08-09 Thread Oliver Yang
Jonathan Adams wrote:
> [ snipped...]
>
> Looking at the ::kmem_cache output:
>
> 32-bit:
>  >::kmem_cache ! grep streams_dblk_1984
> cac2e2b0 streams_dblk_1984 020f 00 2048 9
>
> 64-bit
>  > ::kmem_cache ! grep streams_dblk_1936
> ec0033c08 streams_dblk_1936 0269 00 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
>
> The flags they both have are KMF_HASH (buffers require a hash table to 
> track control structures), KMF_CONTENTS (record contents of buffer 
> upon free), KMF_AUDIT (record information about each allocation and 
> free).
>
> The 64-bit cache is a firewall cache;  this means the buffer size is 
> rounded up to a multiple of PAGESIZE, and all buffers are allocated so
> that the end of the buffer is at the end of a page.  The allocation is 
> then done in such a way that there is an unmapped VA hole *after* that 
> page, and so that allocation addresses are not re-used recently.  The 
> magazine (that is, caching) layer of the cache is disabled, which 
> means that the objects are freed and unmapped immediately upon 
> kmem_cache_free().
>
> The 32-bit cache is a standard debugging cache;  the slabs are five 
> pages long, which is 9 buffers / slab (0x5000 / 0x540); the extra 40 
> bytes is a "REDZONE", used to detect buffer overruns, etc.  The 
> magazine layer is *enabled*, which means that freed buffers are 
> cached, until the system notices that we're running low on space.
>
> The difference only exists on DEBUG kernels, and is because 
> firewalling is not done on 32-bit platforms, since the allocation 
> patterns used waste and fragment VA space.
>
> On a non-debug system, the setup will be pretty much the same between 
> 32-bit and 64-bit systems.
>
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?

Anyway, thanks for your reply, I do learn something from it. :-)

-- 
Cheers,

--
Oliver Yang | Work from home | http://blog.csdn.net/yayong




[mdb-discuss] ::kmastat output different in meaning between x86 32-bit and 64-bit?

2007-08-09 Thread Jonathan Adams
On 8/9/07, Oliver Yang  wrote:
>
> Jonathan Adams wrote:
> > [ snipped...]
> >
> > Looking at the ::kmem_cache output:
> >
> > 32-bit:
> >  >::kmem_cache ! grep streams_dblk_1984
> > cac2e2b0 streams_dblk_1984 020f 00 2048 9
> >
> > 64-bit
> >  > ::kmem_cache ! grep streams_dblk_1936
> > ec0033c08 streams_dblk_1936 0269 00 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>