Date: Sun, 9 Aug 1998 16:08:29 +0930 From: Greg Lehey <grog@lemis.com> To: dg@root.com, John Baldwin <jobaldwi@vt.edu> Cc: FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: AMD-specific kernel code (was: How long a wait?) Message-ID: <19980809160829.A11214@freebie.lemis.com> In-Reply-To: <19980808182200.E14475@freebie.lemis.com>; from Greg Lehey on Sat, Aug 08, 1998 at 06:22:00PM %2B0930 References: <XFMail.980807002452.jobaldwi@vt.edu> <199808070644.XAA14097@implode.root.com> <19980808182200.E14475@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 8 August 1998 at 18:22:00 +0930, Greg Lehey wrote: > (following up to -hackers) > > On Thursday, 6 August 1998 at 23:44:39 -0700, David Greenman wrote: >>> I have a question and I hope this is the right list.. How long is the normal >>> turn around for a response to a non-critical PR? A friend of mine who runs an >>> ISP submitted a PR (6269) that turns on an extra option for AMD K5 and K6 >>> CPU's. He says that it gave his AMD-based webserver a whopping 15% performance >>> increase! He submitted it on Apr 10 of this year (almost 4 months ago) and no >>> one has bothered to even reply to it or anything. As a result, he's somewhat >>> disappointed and not to eager to contribute code in the future as he just >>> thinks he'll get blown off. Of the programmers that I actually know >>> personally, he's the best, and I'd hate for him to not make any further >>> contributions. So, how are PR patches normally handled? Do you wait for >>> enough people to try it out and respond saying it works? I'm just curious, and >>> I wouldn't mind FreeBSD having a patch committed that increases performance by >>> 15% on some machines. Please cc me in replies as I'm not subscribed to >>> questions, thanks. >> >> I just looked at the patch. Other than some KNF style bugs, it seems okay. >> I don't have any AMD K5/K6 machines, however, so I can't test it and won't >> be committing it. >> If it could get wider circulation - perhaps by posting a note to hackers >> asking for testers, then I think there would be less hesitation in getting >> it committed. > > I've grabbed the code and will try it out and report. I've now tried it out. It was suffering from a bit of software rot, but I was able to get it to work, with one puzzling exception: it prints the message "AMD K6 write allocate enabled\n", but it doesn't appear in msgbuf. I've confirmed by setting breakpoints in the code that it does, indeed, go through the code. Does anybody have an idea what could cause this? The effect on CPU performance is also noticable: here are "make world" times: Without write allocate: real 106m58.441s user 63m0.960s sys 20m25.035s With write allocate: real 114m16.402s user 69m41.733s sys 17m54.862s These were only a rough test (I had other stuff running at the same time), but in practice this normally only makes about 1 minute difference. I'd guess that the difference *is* real. Obviously there must be a reason for enabling or disabling this behaviour, and I'd guess that write allocation is most effective when one process is using much CPU time. 'make world' starts thousands of short-lived process, and may thus be the worst-case scenario. In this connection, it's also interesting to note that system time was down and user time was up with write allocation. I have patches available. Does anybody want to commit them? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980809160829.A11214>