Date: Tue, 2 Dec 1997 13:31:33 -0800 (PST) From: Sean Eric Fagan <sef@kithrup.com> To: current@freebsd.org Subject: Re: cvs commit: src/sys/kern vfs_aio.c Message-ID: <199712022131.NAA00912@kithrup.com> In-Reply-To: <3180.881092488.kithrup.freebsd.current@critter.freebsd.dk> References: Your message of "Tue, 02 Dec 1997 10:34:13 PST." <199712021834.KAA06151@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <3180.881092488.kithrup.freebsd.current@critter.freebsd.dk> you write: >I have taken the attitude by now, and I belive I have earned the >right to it, that if people doesn't express themselves so their >emails make sense, then I can safely ignore it. I get too many >emails as it is, and if I have to spend several minutes trying to >figure out what it is that you were complaining about because you >only "allude" to the substance of the complaint, then 'd' is the >fate of the email. Sorry, but that's life. If you are not willing to spend "several minutes" to defend a massive change, then you should not make that change. Sorry, but *that* is life. >On the subject of the change, the majority by number (and as far as I >have been able to measure: by usage) of our syscalls do not use the >retval for anything. Consequently it is a waste of time to move it >around on the stack like we did. A minimal waste of time. Less than 10 cycles, even on the slowest x86, for the initial push. The syscalls that don't use then don't pass it around generally, so there is no additional overhead. You have given *one* reason in support of the change. You have had several *against* the change. The only reason you did not get them earlier is because you did not choose to -- my first message, in response to the commit message, mentioned that it would make some emulation stuff more complex. That was one reason I am against it. It was more justification than you gave for making the change. And what about having to support more than two words of return values? Doing so requires a change to the proc structure -- something that should happen rarely, if at all. (No, we probably will never have a native system call that does that -- but can you guarantee that about Linux, SysVr<x>, NetBSD, BSD/OS?) Once again: the benefits are minimal. If this set of changes made more than 0.1% of a difference in performance, I would be highly surprised. The negative aspects, however, are multiple: emulation gets harder (because we have to do errno mapping, and deal with system calls calling system calls); possible future emulation support gets more difficult (due to the limit of two retval's); the change was made with no discussion, warning, or apparant review (you still haven't said who, if anyone, reviewed the changes); anyone porting code from other sources (either in source or binary form) now has to deal with this. The worst thing about it is that it's a *regression* -- there was a reason that CSRG went away from u.u_ar0 and u.u_ar1, you know. It's *ugly*. And that is what you have re-introduced, albeit with a different name. If you want a performance improvement, I can, and in fact *have*, suggested other areas that could be looked at. But what's a little incompatibility, overhead, and instability, hm? :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712022131.NAA00912>