Re: SF Ballot Counting Keyhole; call for non-GUI keyholes
Fedor Pikus <[email protected]> Sat, 6 Nov 2004 22:45:12 -0800 (PST)
| Newsgroups | gmane.comp.programming.keyholes |
|---|---|
| Message-ID | <Pine.LNX.4.61.0411062220030.4759@lorien> |
Here is a nice juicy one (non-GUI). Actually, more than one lumped
together. Takes a bit of an introduction though:
When AMD came out with 64-bit CPUs, one of the things they realized was
that there are loads of I/O cards which do DMA (direct memory access) for
their memory transfers (all video cards do, all disk controllers, most
network cards, etc), but most of these cards will have 32-bit DMA because
they were designed before a 64-bit PC existed. Rather than requiring all
new hardware for their CPUs, they implemented a hardware solution called
I/O Memory Mapping Unit (IOMMU) which remaps 32-bit DMA accesses onto
64-bit address space. So far so good.
Now enter Intel, who just sunk untold gazillion $$$s into Itanic and needs
a working 64-bit CPU fast. They do a quick and dirty job of cloning the
Opteron and produce Nocona, but leave out few things here and there, IOMMU
being one of them. This throws the problem into the lap of OS writers,
who have to implement a software remapping.
Cue in the Linux kernel. It had for quite a while an obscure feature that
nobody cared about called Software IO Translation Buffer (SWIOTLB).
Suddenly this feature is front and center as Noconas appear on the market.
The buffer must be allcoated in low memory (which is the only one DMA can
reliably access), which means it's allocated early at boot time, before
kernel has to start doling out memory. Once allocated, it cannot be reused
for anything else (because there is no way to grow it back). How much
buffer you need? Depends on how much memory is on the video card and how
much main memory it will try to access through DMA. In other words, the
kernel has no idea how much. It allocates some. What happens if the video
card overruns the SWIOTLB? Two things: kernel panics, and a random address
is returned to the program which requested the allocation (so just in case
you can survive the kernel being yanked from under you you can't get too
far, I guess).
As a user, you know how much memory your video card has, and indeed the
kernel provides an option to specify SWIOTLB size at boot. So, if you are
building a nice gaming PC, you plug in a GeForce 6800 with 256MB of
memory, and suddenly you need to allocate half a gig for SWIOTLB. I guess
we won't be seeing many gaming or 3D graphics PCs with Noconas.
So we have a similar scenario where an obscure keyhole nobody cared about
suddenly became a major keyhole, on top of the keyhole created by Intel's
limited implementation of DMA.
Fedor
On Sat, 6 Nov 2004, Scott Meyers wrote:
> In the meantime, if you come across non-GUI keyhole examples of the kind
> suggested above, please send them to me or post them to this mailing list.
> I continue to believe that GUI keyholes are just a manifestation of a more
> widespread conceptual problem, but additional examples will help me make
> the case more successfully.
>
> Thanks,
>
> Scott
--
Fedor G. Pikus
Mentor Graphics Corporation | Phone: (503) 685-4857
8405 SW Boeckman Road | FAX: (503) 685-1239
Wilsonville, Oregon 97070 | http://www.pikus.net/~pikus/