lkml.org 
[lkml]   [2001]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: zap_page_range in a module
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/

\
 
 \ /
  Last update: 2005-03-22 13:14    [W:0.052 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site