lkml.org 
[lkml]   [1998]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 4MB pages and framebuffer access, x11perf results, 2.1.125

Having not delved into the Linux kernel, I'll not comment on implementation
problems and tradeoffs.

Here's my analysis of the situation:

1) On some architectures, in fact, it is a non-issue for frame buffers
(if memory serves me, on MIPS certain address ranges avoid the TLB
altogether). I have vague memories of us (Digital) on MIPS hacking things
so that these addresses were available to the X Server, and that the display
frame buffer was mapped to those addresses. It's been too long for me
to remember the details; that was around 1989-1991. On other architectures
(with software TLB's), a (hackish) solution is to allocate the large TLB(s)
entries explicitly in the frame buffer device driver initialization.
In either case, one then hides this behind a architecture specific interface.

2) In fact, you should consider the frame buffer a special case of a more
general problem; the issue comes up in any window system implementation
(or even client library) drawing to off screen memory, where the primary
CPU gets to do the work whenever there is insufficient off screen memory
to do the graphics with the aid of an accelarator. For small areas,
it typically doesn't matter much; its when the stride of the pixmap gets
large that you tend to get into trouble with TLB faults.

3) the issue comes up in other applications, for example numerical codes, if
they access in row rather than column order on large arrays. To me, in
fact, this is the most compelling potential application, possibly more
so than for the X11, if hack 1) has been implemented (or the frame buffer
has a good graphics chip such that relatively little stuff has to be done
in the processor).

This tells me two things:

a) there is a (hackish) solution suitable just for the frame buffer situation.
That might be "good enough" for the current situation (to get competative
window system performance on relatively stupid hardware frame buffers).
While there is some off screen drawing performed, it dominant in total
time as far as I am aware (though maybe the Enlightenment folks with their
video game on steroid screens push things in this direction). Even so,
most drawing is done by applications on visible windows, so I'd be surprise.

b) madvise() could be used to inform the VM implementation that such bad
locality behavior is expected. When possible, the system might honor
the request. This would be generally useful to applications, both window
system and other applications that can predict such behavior. In
the X case, it would be relatively easy to add code to use madvise().
(if the stride is large on certain in-memory pixmaps, then bother to
do the system call; otherwise not; overhead is probably not an issue,
as the first thing you do with a large pixmap is typically clear it
entirely, and for a large one, that is alot of work).

Whether it is worth doing a general solution, and what such an implementation
should look like, and whether more than the hack solution is appropriate,
I don't know off hand (and I'm completely ignorant of x86 paging hardware).
If there is interest, I can try to find out if for Digital UNIX on Alpha
it has been worth doing more than hack 1) (I think that we also may use
the large TLB entries for shared libraries, if memory serves). -
- Jim Gettys




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

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