Re: sched_setaffinity usability

[Davide Libenzi]

On Thu, 18 Mar 2004, Ingo Molnar wrote:

> 
> * Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote:
> 
> > > Right now the VDSO mostly contains code and exception-handling data, but
> > > it could contain real, userspace-visible data just as much: info that is
> > > only known during the kernel build. There's basically no cost in adding
> > > more fields to the VDSO, and it seems to be superior to any of the other
> > > approaches. Is there any reason not to do it?
> > 
> > With /proc/something you can have a single piece of code for all archs
> > that exports NR_CPUS. The VDSO should be added to all missing archs.
> > IMO performance is not an issue in getting NR_CPUS from userspace.
> 
> you just cannot beat the mapping performance of a near-zero-overhead
> (V)DSO. No copying. No syscalls to set it up. No runtime dependencies on
> having some filesystem mounted in the right spot. Already existing
> framework to handle various API issues. Debuggers know the layout.

Talking about performance for a function that returns NR_CPUS seems a 
little out of scope IMO (I'd rather exclude tight loops calling sysconf, 
since the info will be const). My objection was more to look at the 
standard way we currently have to export information toward 
userspace/glibc. At this time /proc/ is a standard supported by all 
architectures. The (V)DSO is currently not. If the (V)DSO would have been 
a standard, we wouldn't have had this conversation ;)



- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/