Date: Mon, 22 Jan 2001 12:54:44 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Robert Lipe <robertlipe@usa.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122125444.C26076@fw.wintelcom.net> In-Reply-To: <20010122145550.O10504@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Jan 22, 2001 at 02:55:50PM -0600 References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> <20010122121033.A26076@fw.wintelcom.net> <20010122145550.O10504@rjlhome.sco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Robert Lipe <robertlipe@usa.net> [010122 12:50] wrote: > Alfred Perlstein wrote: > > > > So if I sandbagged the allocs to be *larger* the KMA would behave more > > > consistently with what I'd expect becuase it would then reclaim? I > > > didn't see that one coming. :-) > > > > but... this is a terrible workaround, I'm not sure it would work > > and you shouldn't do it. :) > > Good. I didn't actully *want* to do that. I still have to respect > myself in the morning. :-) > > > > Is there an s/g memory interface in FreeBSD? This was my first choice, > > > > See the busdma stuff, > > Yes, this looks to be much closer to the interface I really wanted > anyway. I see no man pages for them. Is there any doc anywhere? "Read > the source and look at existing examples" will do if it must but any > pointers to better doc are appreciated. I know of no docs, I don't write drivers. (lucky me) > > there's a problem because there's no busdma > > for mbufs (well actually there is but it fails on really small > > unaligned blocks which basically breaks it for mbufs). > > Can you tell me more about this hazard? I can't control the alignment > that's asked for by the driver, but I can certainly fudge the size and > alignment of the request by the time it gets to this interface. Just > tell me the rules. :-) I don't know, Bill Paul explained that the normal busdma stuff is pretty broken for chunks too small. Basically, disks work, network cards won't because mbufs are too small. > > ack, I'd review patches if you wanted to write/port busdma for mbufs.. > > Thanx for the offer, but I'm hoping to avoid that right now. > > It's very much a goal of mine (esp. now that we're in the final days > of the NDA requirement) to stamp out something that works on shipping > FreeBSD well enough for this crowd to see what remains to be done and > see where we are. Then we can figure out how to improve interfaces or > otherwise enhance the base OS if we want to. So given a choice between, > say, incurring an extra copy in a data path and porting busdma for mbufs > I'll take the former for now. With mbufs you're stuck. I have some code that needs to send > PAGE_SIZE chunks of data down the network stack, my current "hack" is that I prebuild the mbuf packets and split them on page boundries, then just call m_copym on the chain, but I doubt that'll help you. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20010122125444.C26076>