Subject: Re: tsleep
To: Mirian Crzig Lennox <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 07/06/1999 11:48:34
On 06 Jul 1999 14:31:15 -0400
Mirian Crzig Lennox <firstname.lastname@example.org> wrote:
> > Um... It's NOT "two distinct symbol tables".
> In most cases, it really is. For example, in /sys/kern/vfs_subr.c we
> In vinvalbuf():
> tsleep((caddr_t)bp, slpflag | (PRIBIO + 1), "vinvalbuf",lptimeo);
> In vflushbuf():
> tsleep((caddr_t)&vp->v_numoutput, PRIBIO + 1, "vflushbuf", 0);
> In vget():
> tsleep((caddr_t)vp, PINOD, "vget", 0);
> In vgone():
> tsleep((caddr_t)vp, PINOD, "vgone", 0);
> In effect, we're duplicating information that already exists in the
> kernel symbol table.
The point is that tsleep() is more flexible than that. What if you sleep
in two different places in the same function, and want to differentiate?
> If tsleep() were changed such that the calls could be:
> tsleep((caddr_t)bp, slpflag | (PRIBIO + 1), (caddr_t)vinvalbuf,lptimeo);
> Then we'd get back 27 bytes "for free". Maybe not a lot, but why
> waste any space if you don't need to? And in the aggregate, it could
> easily be a few K of kernel mem.
The "savings" is a lot less important when you consider that:
(1) Constant strings are placed into the .text or .rodata
sections (.rodata lets loaded w/ .text).
(2) That combined section is always rounded to a page
...this "savings" would have to be *considerable* to even consider
throwing away the (sometimes very very very very useful when debugging)
flexibility that having that wchan message provides.
-- Jason R. Thorpe <email@example.com>