> On Sun, 10 Nov 2002, Pavel Machek wrote:
> >
> > Unfortunately, this means "bye bye vsyscalls for gettimeofday".
>
> Not necessarily. All of the fastpatch and the checking can be done by the
> vsyscall, and if the vsyscall notices that there is a backwards jump in
> time it just gives up and does a real system call. The vsyscall does need
> to figure out the CPU it's running on somehow, but that should be solvable
> - indexing through the thread ID or something.
I'm planning to store the CPU number in the highest bits of the TSC ...
> That said, I suspect that the real issue with vsyscalls is that they don't
> really make much sense. The only system call we've ever found that matters
> at all is gettimeofday(), and the vsyscall implementation there looks like
> a "cool idea, but doesn't really matter (and complicates things a lot)".
It's not complicating things overly. We'd have to go through most of the
hoops anyway if we wanted a fast gettimeofday syscall instead of a
vsyscall.
> The system call overhead tends to scale up very well with CPU speed (the
> one esception being the P4 which just has some internal problems with "int
> 0x80" and slowed down compared to a PIII).
>
> So I would just suggest not spending a lot of effort on it, considering
> the problems it already has.
Agreed. The only problem left I see is the need to have an interrupt of
every CPU from time to time to update the per-cpu time values, and to
synchronize those to the 'global timer interrupt' somehow.
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/