Roland McGrath <roland@redhat.com> wrote:
>
> > This doesn't apply against Linus's current tree.
>
> Ok. I don't use bk, but I can update relative to the latest snapshot on
> kernel.org.
Yup. The best place usually is the first link here:
http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
the "Gzipped full patch".
> > Your patch increases the kernel text by nearly 1%. That's rather a lot for
> > what is a fairly esoteric feature.
>
> Agreed. I hadn't thought about that angle. I am open to suggestions on
> other ways to make it work.
>
> > Would it be possible to avoid this by just taking the fault and fixing
> > things up in the exception handler?
>
> There is no fault that would be taken.
oop, very true.
Nasty. Maybe the best approach is to mostly uninline the access_ok()
check. Do the check for constant-sized small copies first, so those guys
still do the access_ok() check inline; uninline the rest.
It'll hurt the microbenchmarks (again), but it's a general article of faith
that keeping the kernel's cache footprint small is a net win...
Let me think about that for a bit.
> > For some reason the patch causes gcc-2.95.3 to choke over the
>
> You got me. That version of gcc has many, many bugs and is long obsolete.
> Random meaningless perturbations of the code might change its behavior.
Turns out that it only happens with `-O1'. -O2 is OK. I use -O1 because
it is faster. I use gcc-2.95.3 because gcc-3.x is unacceptably slow.
-
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/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:30 EST