Possible evidence of performance regression for 8.1-S (vs. 7.1)

[David Wolfskill]

On Fri, Oct 22, 2010 at 05:07:52PM -0700, Julian Elischer wrote:
> On 10/22/10 4:48 PM, David Wolfskill wrote:
> >On Fri, Oct 22, 2010 at 04:17:30PM -0700, David Wolfskill wrote:
> >>On Wed, Oct 20, 2010 at 04:50:10PM -0700, Julian Elischer wrote:
> >>>...
> >>>try the 7.x machine but running the 8.x kernel.. i.e. change nothing,
> >>>but boot the new kernel.
> >>I just started that test, to run over the weekend.
> >>...
> >Moot point: the build fails.
> >
> that shouldn't happen
> maybe you need to set the uname vars so that the build THINKS it is on 7.x

OK; poking through the source tree, I found quite a few references to
uname -- and several to kern.osreldate.

I tried setting UNAME_r to a value that gegins with "7.1-RELEASE", and
the build ran, completing with a status code of 0.  I'm not especially
confident that the result of the build was equivalent -- some of my
statistics-gathering was a bit warped by the experience, but appears to
be salvagable.

I've fired off a sequence of 5 iterations of the test build, with the
UNAME_r set as above; we should have answers (to the question of the
rusage data for 8.1-S kernel and 7.1-R+ userland) by Monday.

Thanks!

> ...
> it's not unusual to have to do this when cross building with a 
> different kernel.

:-}  OK; I confess that it hadn 't occurred to me that this would be
useful, let alone expected to work.  (Sure, I expect some basic stuff to
function in that environment, but with more "moving parts," I get a tad
nervous.)

> Running an 8.x kernel with the 7.x userland is a crucial part of 
> debugging this.
> we really can't do much more until we have the results.

We should have them, as above.

> If the build fails. it's either becasue the build detects the kernel 
> rev (which we want to
> stop with this) or because of a bug in 8.1. It's supposed to be 
> downwards compatible.

Well, I know that there were some changes made to our build in order to
get it to even work under 8.x at all; I suppose I can be thankful that
those seem to be based on uname values, vs. kern.osreldate.  :-}

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20101024/05e01924/attachment.pgp