Re: More breakage in native_rdtsc out of line in git-x86

[Andi Kleen]

On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
> 
> * Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> 
> > On Wed, Jan 09, 2008 at 04:22:08PM +0100, Ingo Molnar wrote:
> > > 
> > > * Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> > > 
> > > > > nope, it's a 64-bit setup/dependency bug/problem: the vsyscall mappings 
> > > > > are installed via an __initcall, and that's too late for early use. The 
> > > > > combo patch below fixed the crash for me, does it work on your box too?
> > > > 
> > > > That gives
> > > > 
> > > > /home/lsrc/quilt/linux/arch/x86/kernel/setup_64.c: In function 'setup_arch':
> > > > /home/lsrc/quilt/linux/arch/x86/kernel/setup_64.c:468: error: implicit declarati
> > > > on of function 'map_vsyscall'
> > > 
> > > i guess you have an old repository.
> > 
> > I just applied the patch you sent out against yesterday's git-x86.
> 
> then you have a truly ancient x86.git repository ;-)

I update only infrequently because frankly git's remote branch tracking
is a mess. At least it doesn't really work for x86#mm here. 

I usually have to blow away the repository and reclone
to get back to a sane state.

> 
> think of x86.git#mm as an open development tree. It's high-flux, based 
> against Linux-bleeding-edge, it's frequently updated (daily, sometimes 
> hourly), breakages are possible (and likely) and fixes and other 
> feedback is more than welcome. And please feel free to complain about 

Right now Jan's cpa change you merged makes the cpa selftest to not pass 
anymore on 32bit. While that was likely a latent bug it just
triggered it's a little inconvenient.

There's also the problem on NX handling still not being right.

> patches that are included. (like you did in the past) Also please try to 
> post your patches as early as possible instead of in big chunks - last 
> week's 75 patches patchbomb from you was (and still is) ... challenging

There are still quite a lot outstanding. 

% wc -l patches/series 
90 patches/series

Some of that is debug or tbd or obsolete, but most isn't.

> > > since yesterday there's a full barrier around rdtsc.
> >
> > Great.
> 
> i have measured the impact of the barriers and it was in the noise 
> level. Barriers are notoriously easy to get wrong (because almost 
> nothing tells the programmer that they are wrong), that's why i did this 
> barrier-safe rdtsc() [& friends]. We had so much trouble with RDTSC 
> during the past 10 years of its existence that being a bit more 
> conservative with it is the only really maintainable option.

I would still think that the explicit barriers would make this 
all clearer, with long term giving cleaner semantics.

Admittedly I should have written some more comments in the
code.

I'm also a little unhappy on how many function calls the vgtod()
fast path contains now. Long ago it was a really lean function,
but it gets messed up more and more. Back when ->vread was introduced
the latency already suffered significantly (iirc multi digit
percent range), i suspect it now got worse again.

And after all that's still by far the most common system call
(not only for databases; i profiled this using systemtap in some
loads some time ago and it usually came up with >50%) 
and quite important for many workloads.

We have a lot far uglier code for less gain in far less critical calls.

-Andi

--
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/