> James Sutherland wrote:> > > > On Mon, 22 Jan 2001, Helge Hafting wrote:> > > > > And when the next user wants the same webpage/file you read it from> > > the RAID again? Seems to me you loose the benefit of caching stuff in> > > memory with this scheme. Sure - the RAID controller might have some> > > cache, but it is usually smaller than main memory anyway.> > > > Hrm... good point. Using "main memory" (whose memory, on a NUMA box??) as> > a cache could be a performance boost in some circumstances. On the other> > hand, you're eating up a chunk of memory bandwidth which could be used for> > other things - even when you only cache in "spare" RAM, how do you decide> > who uses that RAM - and whether or not they should?> > If we will need it again soon - cache it. If not, consider > your device->device scheme. What we will need is often impossible to> know,> so approximations like LRU is used. You could have a object table> (probably a file table or disk block table) counting how often various> files/objects are referenced. You can then decide to use RAID->NIC> transfers for something that haven't been read before, and memory> cache when something is re-read for the nth time in a given time> interval.

I think my compromise of sending it to both simultaneously is better: ifyou do reuse it, you've just got a cache hit (win); if not, you've justburned some RAM bandwidth, which isn't a catastrophe.

> This might be a win, maybe even a big win under some circumstances. > But considering how it works only for a few devices only, and how> complicated it is, the conclusion becomes don't do it for > standard linux.

Eh? This is a hardware system - Linux has very little hardware in it :-)

> You may of course try to make super-performance servers that work for> a special hw combination, with a single very optimized linux driver> taking care of the RAID adapter, the NIC(s), the fs, parts of the> network stack and possibly the web server too.

Actually, I'd like it to be a much more generic thing. If you get an"intelligent" NIC, it will have, say, a StrongARM processor on it. Whyshouldn't the code running on that processor be supplied by the kernel, aspart of the NIC driver? Given a powerful enough CPU on the NIC, you couldoffload a useful chunk of the Linux network stack to it.

Or a RAID adapter - instead of coming with the manufacturer's proprietarycode for striping etc., upload Linux's own RAID software to the CPU. Runsome subset of X's primitives on the graphics card. On an I2O-type system(dedicated ARM processor or similar for handling I/O), run the low-levelcaching stuff, perhaps, or some of the FS code.

Over the next few years, we'll see a lot of little baby CPUs in our PCs,on network cards, video cards etc. I'd like to see Linux able to takeadvantage of this sort of off-load capability where possible.

James.

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgPlease read the FAQ at http://www.tux.org/lkml/