Matty wrote:
Howdy,

While reading through the source code for read():

http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/syscall/rw.c

I came across the following:

/*
    168      * Only use bypass caches when the count is large enough
    169      */
    170     if (bcount < copyout_min_size)
    171         auio.uio_extflg = UIO_COPY_CACHED;
    172     else
    173         auio.uio_extflg = UIO_COPY_DEFAULT;

    [ ..... ]

Could someone shed some light on what a bypass cache, and where the

On most SPARC implementations, you can read and write data from/into
memory directly without touching L2.
This is good for performance
when the data in question is relatively large
(bigger than L1 and sizable chunk of L2),
because doing so won't blow away everything else in the cache.

On some x86, there are special variant of stores that mark cache lines
differently so that they don't blow away other cached data
(e.g. use only 1-way of n-way associative cache, or don't update LRU, etc).
They don't necessarily "bypass" the cache
but the goal and the end result is similar
- don't blow away everything else in the cache to store/load this data.

The cached-vs-default is that - whether to use cached variant of store/load
or not.

magic value 128k (value of copyout_min_size) comes from?

I believe this is more of a heuristically determined value.
It is usually bigger than L1 size, and typically less than L2 size.
The exact optimal value can vary depending on the platform
but 128k is probably a pretty good default for most contemporary platforms.

Having said that, I'm a compiler writer and not a kernel/filesystem guru,
so there might be other nuances specific to the file system implementation
that I'm totally ignorant.

Seongbae

Thanks,
- Ryan
--
UNIX Administrator
http://daemons.net/~matty
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to