Date: Wed, 21 Aug 2002 08:06:29 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Ian Dowse <iedowse@maths.tcd.ie>, <arch@FreeBSD.ORG> Subject: Re: Solving the stack gap issue Message-ID: <20020821073943.W25211-100000@gamplex.bde.org> In-Reply-To: <15714.17605.575558.398279@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Aug 2002, Andrew Gallatin wrote: > Bruce Evans writes: > > > > I'd like normal calls to have a fast path. We're already 1 or 2 layers > > slower than Linux. (Linux on i386's does something like > > "pushal; call syscalltable(,%eax,4)" for the fast path, so it goes directly > > from the lowest layer to sys_foo(), but FreeBSD calls syscall() from the > > lowest label and syscall() does lots of relatively slow things.) > > Is there any chance of getting this fastpath? Or at least making > syscall() more streamlined? It's harder than it was before syscall() accumulated a lot of cruft. Linux starts a little cleaner by passing the first few args in registers so that we don't have to do copyin()s to read them. I've thought about doing the copyin()s more efficiently. Iterated fuword()'s may be faster, especially if there is only 1 iteration. On i386's, the fuword()'s can easily be optimized to 1 bounds check (the one at the beginning of fuword()) and direct accesses plus lazy trap handling. So passing args on the user stack instead of in registers need not be significantly worse than passing args on the stack for general function calls, at least on i386's. > For example, why do we check MPSAFE and conditionally grab and release > GIANT in syscall instead of just grabbing/releasing it in the syscall > itself? A few thousand instructions worth of bloat might be worth 2 > compares in the critical path.. Well, it's better not to grab it at all. The syscall path is not as critical as some. See other replies about how we are almost ready to finish pushing down Giant locking to individual syscalls and removing MPSAFE. I counted about 130 syscalls which still depend on syscall() handling Giant. > Also, if the copyin fails, why do we > not just set the ret value and jump past the call, rather than setting > error and doing an extra compare a few lines later? This is an error case, so it is not in the fast path. Actually, handling errors lazily like this seems to introduce bugs. We call ktrsyscall() unconditionally in the error case, but the args are stack garbage if the copyin() failed. Quite a bit of the non-fast-pathness in syscall() is caused by wanting to fall through through to do things ktrace checks in all cases. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020821073943.W25211-100000>