Re: [PATCH v2] x86: Remove compat vdso support

[Stefani Seibold]

Am Dienstag, den 11.03.2014, 10:09 -0700 schrieb Linus Torvalds:
> On Tue, Mar 11, 2014 at 9:50 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> > Looking forward, would it be reasonable to have an extensible set of
> > flags that live in the ELF interpreter's headers somewhere
> 
> No. Not reasonable. The whole "32-bit x86" and "looking forward"
> combination makes absolutely zero sense.
> 
> I can pretty much guarantee that even *phones* will be 64-bit if/when
> x86 ever gets there. They'll need it just for ARM emulation, I bet.
> 
> So 32-bit x86 is dead, dead, dead. There's absolutely no future to it.
> We're not adding new stuff to "future-proof" it.
> 

Quite frankly this sounds like the mad scientist in an old marvell
comic: "dead, dead, dead".

Is it possible to calm down and get a more technical discussion rather
than blaming and treats not to accepting patches?

Can we also stop this hard words like "WTF". I don't like this style and
other developers too, especially women.

32-bit is not dead. I think 98 percent of all computers running linux
are embedded devices and a lot of them are not capable for 64 bit
support. So its your opinion, but there a also developers not sharing
this.

For me i still work with old Celeron Pentium III devices. And the life
time of this device will end in 7 years.

A lot of peoples (also main kernel hackers) ask me to do this patch
because the time functions in 32 bit kernel mode are so slow compared to
a 64 bit linux. And as i can see most of the involved kernel developers
are not opposite against this patch.

The other side is that many embedded developers use hand crafted time
functions using TSC or similar to get a fast time functions, but did not
know the pitfalls (C- and P-States) to handle this in a right way. So a
reliable way is to use the kernel functions, because the kernel knows
the state of the CPU and always returns the correct time. But this will
result in a slow down of the application, which generates latency.

We use this kind of patch for a long time and it decreased the latency
of our applications notable.

The current solution is quite clean, but there was a issue with the size
of the vDSO which not fits into one page by some kernel configurations. 

There is a solution for this to #undef CONFIG_OPTIMIZE_INLINING and
CONFIG_X86_PPRO_FENCE in arch/x86/vdso/vdso32/vclock_gettime.c. 

To prevent issues which future kernel releases, we have now two ideas to
solve this:

One ist Andy's kick ouf of the compat VDSO. For this there is already a
patch there.

And the other one is (thanks to Andys archeology investigations) to
increase the size of the vDSO fixmap space which has according to Andy
no side effect. This can be done in a very clean and easy way. The code
is still there, since the fixmap area is not fix:

Lguest, XEN, OPLC and the reservetop will move the fixmap during boot,
so we can easily get additional space by fixing __FIXADDR_TOP.

I will write a patch for the later one.

- Stefani


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