Messages in this thread | | | Date | Fri, 9 May 2003 02:19:21 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] i386 uaccess to fixmap pages |
| |
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/
| |