Date: Mon, 19 Jun 2000 18:27:30 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619182730.L37084@prism.flugsvamp.com> In-Reply-To: <200006192311.QAA10064@mass.osd.bsdi.com> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192311.QAA10064@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 19, 2000 at 04:11:59PM -0700, Mike Smith wrote: > > And as far as "zero-copy" goes, I would consider that a fairly overloaded > > term. Here, I'm applying it to anything that saves copies, not just > > a magical method of getting data between user and kernel spaces. > > Correct. Note that kblob doesn't involve any more copies than absolutely > necessary. Not quite true. You can't load your "static image" into the kernel directly from disk. You have to go through userspace. That counts as an extra copy in my book. Now it may be true that you may not need to do this for _YOUR_ application, but that may not be applicable for mine. > > > > And for a lot of cases > > > > you don't need stuff to actually go to user space. In many situations, > > > > you will receive data, perform operations on a very small part of it, > > > > and then send the data elsewhere, whether to disk or network. > > > > > > However, for a user-space application to do this, you want it to come out > > > to user-space, right? > > > > No. You cut out what I wrote - you may only need a very small part > > of the data to actually go to user space. > > However, it still has to go there, right? That being the actual point. No, it does not. What part of that do you not understand? The bulk of the data _NEVER_REACHES_USER_SPACE_. Ever. > > > Irregardless, this is irrelevant in this context. > > > > Not irrelevant; you're not looking at the big picture here. > > Actually, I think I'm looking at a *bigger* picture - what can we do to > make FreeBSD a better platform for real-world applications? > > The ability to send static content in the most efficient manner possible > is a key "big picture" item. You're so tied up in what would be the most > wonderful engineering solution that you're completely ignoring this. Gee, really? Please explain to me in small words how what I'm trying to accomplish is contrary to what you're saying above. Please explain how the rough API I posted is at all at odds to above. Please explain to me how "static content" is the end-all and be-all "big picture". Until you do so, I will keep going and solving some real-world applications that are larger than just serving static content. > I don't think that anyone *cares* about what you have at this juncture. > What you're threatening will have so many complex options and > implementation issues that it will entirely fail to address the actual, > real-world problems that the big-picture people are looking at. It does? Do you actually know that I'm aiming for? > > > > Again, this is not addressed in the kblob API. Don't throw sendfile() > > > > up as an example, because I want the data to be kept in the kernel > > > > after being read from disk. > > > > > > It is. You remember that thing called the buffer cache? > > > > Not applicable here. If it was, why the heck aren't you using sendfile > > in the first place and relying on the kernel to keep the file cached? > > Hmm? If that was the way things worked, why isn't sendfile() good enough? > > Because it's _still_too_expensive_. Kblob is about _performance_, not > "technical elegance". I happen to agree with that. See the part above that says "not applicable"? > > > No. Since the data in a kblob came from userspace, and can't be modified > > > in the kernel, this would be pointless. > > > > Exactly. You're looking at kblob as a "static send-only buffer which > > comes from user space". I'm looking at kblob as an "in-kernel object > > cache". The two views are _NOT_ that far apart, and with a little API > > help, the current code can be made much more flexible. Why are you > > opposed to that? > > Why would anyone be opposed to putting a Perl interpreter in the kernel? And I thought that -arch was supposed to be a technical list, not the place for ad homenium attacks. > > > Again, folks; kblob is an optimisation for a very common performance > > > case, not a network engineer's wet dream. It's meant to address a > > > real-world problem in an efficient fashion. > > > > It is a narrow optimization for a specific problem. > > Correct. It just happens to be a specific problem that comes up _very_ > often. > > As I've already proposed, kblob should be implemented as a loadable > system call. It'll do what it's meant to do, for the people that want it > to do it, and the rest of you can ignore it in happiness. > > You're welcome to your API, but you need to face the fact that it's just > as irrelevant to kblob's target audience as kblob is to you. Methinks that you haven't actually read what I posted, otherwise you wouldn't be saying that. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000619182730.L37084>