lkml.org 
[lkml]   [2005]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: what's next for the linux kernel?
From
Date
On Mon, 03 Oct 2005 01:54:00 BST, Luke Kenneth Casson Leighton said:

> in the mid-80s), hardware cache line lookups (which means
> instead of linked list searching, the hardware does it for
> you in a single cycle), stuff like that.

OK.. I'll bite. How do you find the 5th or 6th entry in the linked list,
when only the first entry is in cache, in a single cycle, when a cache line
miss is more than a single cycle penalty, and you have several "These are not
the droids you're looking for" checks and go on to the next entry - and do it
in one clock cycle?

Now, it's really easy to imagine an execution unit that will execute this
as a single opcode, and stall until complete. Of course, this only really helps
if you have multiple execution units - which is what hyperthreading and
multi-core and all that is about. And guess what - it's not news...

The HP2114 and DEC KL10/20 were able to dereference a chain of indirect bits
back in the 70's (complete with warnings that hardware wedges could occur if
an indirect reference formed a loop or pointed at itself). Whoops. :)

And all the way back in 1964, IBM disk controllers were able to do some rather
sophisticated offloading of "channel control words" (amazing what you could do
with 'Search ID Equal', 'Transfer In-Channel' (really a misnamed branch
instruction), and self-modifying CCWs). But even then, they understood that
it was only a win if you could go do other stuff when you waited....

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-10-03 04:58    [W:0.171 / U:22.256 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site