Re: zap_page_range in a module

Helge Hafting (helgehaf@idb.hist.no)
Tue, 18 Dec 2001 14:04:53 +0100


Martin Diehl wrote:
>
> On Fri, 14 Dec 2001, Benjamin LaHaise wrote:
>
> > > I have a 64k sliding "window" into a 1MB region. You can only access
> > > 64k at a time then you have to switch the "bank" to access the next
> > > 64k. Address 0xa0000-0xaffff is the 64k window. The actual 1MB of
> > > memory is above the top of memory and not directly addressable by the
> > > CPU, you have to go through the banks.
> >
> > Stop right there. You can't do that. The code will deadlock on page
> > faults for certain usage patterns. It's slow, inefficient and a waste
> > of effort.
>
> Would you mind giving a hint how the predicted deadlock path would look
> like or what the usage pattern might be, please?
>
> I'm asking because I'm happily doing something very similar to what
> Matthew describes without ever running into trouble - and this operates
> at major page fault rates up to 1000/sec here. What I'm doings is:

Some processors have instructions that require 2 or more pages
present simultaneously to execute. That _will_ fail
spectacularly if the two pages belongs to different banks
in the above scenario, as only one bank can be present at a time.

Some examples for x86 processors:

1. The string move/compare instructions. Fine for copying blocks of
memory around. The above case is a framebuffer, using
"movsd" to copy from one location to another isn't
all that uncommon. The two locations might be in different banks.

2. An unaligned read or write, such as writing a 32-bit quantity
to the last even address in the first bank. The the rest hits
the first part of the next bank. (A 16-bit quantity written to
the last odd address does the same thing.)

3. An instruction that cross a bank bounddary, or lives in one
and access data in another bank. Of course you don't usually
store instructions in a frame buffer. :-)

4. Processor-specific structures (page tables, interrupt
vectors... stored so they cross a bank.) Not applicable
to framebuffers, but there might be strange machines with
bank-switched main memory around.

In any of these cases, the following happens:
1. You get a page fault for the page in the missing bank.
2. The page fault handler switch banks.
3. The instruction is restarted as the page fault handler returns
4. You get a page fault for the now missing page in the bank
that was switched off.
5. The page fault handler switch banks
7. the instruction is restarted. Repeat from 1 in
an endless loop. Your machine is now deadlocked. Perhaps
you're so lucky that some other processes still gets
scheduled - lets hope none of them need the bank-switched
memory _at all_.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/