Messages in this thread | | | Date | Thu, 29 Oct 1998 13:50:05 -0800 | From | (Jim Gettys) | Subject | Re: 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/
| |