Date: Fri, 19 Jan 2001 10:15:06 +1100 From: Greg Lehey <grog@lemis.com> To: Duncan Barclay <dmlb@dmlb.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ray if_ray_oldcard.h if_ray.c if_ray Message-ID: <20010119101506.C376@sydney.worldwide.lemis.com> In-Reply-To: <XFMail.010118075552.dmlb@computer.my.domain>; from dmlb@dmlb.org on Thu, Jan 18, 2001 at 07:55:52AM -0000 References: <20010117234218.A10890@sydney.worldwide.lemis.com> <XFMail.010118075552.dmlb@computer.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 18 January 2001 at 7:55:52 -0000, Duncan Barclay wrote: > > On 17-Jan-01 Greg Lehey wrote: >> On Wednesday, 17 January 2001 at 9:55:01 -0800, Duncan Barclay wrote: >>> dmlb 2001/01/17 09:55:01 PST >>> >>> Modified files: >>> sys/dev/ray if_ray.c if_rayvar.h >>> Added files: >>> sys/dev/ray if_ray_oldcard.h >>> Log: >>> Take advantage of the fixes to the pcic code that allows multiple >>> active memory maps. This removes the need to change the memory >>> map from common to attribute every time a packet is sent/received. >>> >>> This increases performance and decreases cpu load (ping times on >>> slow machines improve by about 1.5ms). >>> >>> Move out the old common memory/attrbiute memory hack functions to a >>> new header file to tidy up the main code. I want to keep them available >>> for a while. >> >> Does this require more than 48 kB total memory space? In that case, >> it won't work on the Dell Inspiron 7500 unless we can somehow map >> above 0xe0000. The only way I got the ray driver to work on the 7500 >> was to map cm and am to the same address. > > Yes, this does require 52kB space in total. Where the maps occur are more > to do with OLDCARD than with the ray driver. I'm going to have go > at tidying up some of the pccardd/OLDCARD memory interactions and will try > and get this fixed. > > The performance hit of continually re-mapping the memory areas is > really high. I haven't forgotten about the bank switching idea we > discussed a couple of weeks ago, but I have concentrated on the ping > times. I did some ktr hacks in the driver and looked at the time it used. There were only about 10 remaps per packet, each at 5 µs, but I think most of that time was the KTR_EXTEND overhead. I don't think that the remap overhead was the reason for the slow performance. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010119101506.C376>