Re: X window's 'size' = 20G
On Thu, Apr 18, 2002 at 01:05:28AM +1000, Richard Heycock wrote:
>
> I recently upgraded to X 4.1.0-15 only to find my machine grid to a
> halt. I ran top and the size is around 20GBytes (ps -o m_drs reports
> 21001548). While I know that this is not the amount of real memory,
> I am curious about the huge size.
>
> Machine details: XL300, 160MByte memory, Matrox G200.
>
> Output of top:
>
> PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
> 1986 root 9 -10 20.0G 30M 4048 S < 20G 1.6 19.6 1:23 XFree86
>
> output of ps -p 907 -o args,pmem,rss,rsz,tsiz,m_drs
> COMMAND %MEM RSS RSZ TSIZ DRS
> X :0 15.4 24480 24480 2411 21001548
>
> Any ideas?
Oh, yes... ;-}
The short answer is to look at some code from:
xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_video.c:mapVidMemSparse()
/****************/
lnxBase = mmap((caddr_t)0, 0x100000000,
PROT_READ | PROT_WRITE,
MAP_SHARED, fd,
(off_t) bus_base);
lnxSBase = mmap((caddr_t)0, 0x400000000,
PROT_READ | PROT_WRITE,
MAP_SHARED, fd,
(off_t) _bus_base_sparse());
/****************/
Yes, that's right, it mmap's 20GB of space.
The "why" (ie the long answer), is a bit more complicated... ;-}
First off, XLT300 is one of the so-called SPARSE Alphas, in that it
requires a bit of indirection in order to bang on the PCI bus with
byte and short data lengths. In order to do that we use what is known
as "sparse addressing"; for more details please see the discussion
contained in the PC164 Technical Reference Manual, Appendix A, found
at:
http://ftp.digital.com/pub/Digital/info/semiconductor/literature/pc164trm.pdf
Such accessing is most frequently needed, not for graphics framebuffer
manipulation, but for read/write of graphics controller registers which
are not always 32-bits long, especially on older cards.
Now, in order for the driver writers in XFree86 to not have to know
that they are on Alpha, and that they need SPARSE accesses, the
infrastucture was set up to *completely* map the 4GB PCI bus address
space, not once, but twice; once for normal ("dense" aka 32-bit)
access, the second time for "sparse", this latter taking a multiple
(should correctly be 32x, but luckily was only 4x in the code) of the
4GB PCI bus address space (refer to the document above for why).
This was *serious* overkill, but as a first cut did make it unnecessary
for driver writers to know the Alpha details.
On Alpha, the page tables for that 20GB of address space take up 20MB,
IIRC. This has a *large* impact on machines with small memory
configurations, since those page tables cannot be paged out and consume
kernel Subsequent.
The subsequent 4.2.0 release of XFree86 has some patches that pretty
much do away with this technique, and map *only* what is necessary,
yet still make it transparent to the driver writer. Typical usage on
"sparse" machines is back down to the 15-25 MB range (as was the case
with 3.3.x releases, IIRC), and is not significantly different from
the amount used on non-"sparse" machines.
So, I think your options are to either find/build 4.2.0, or go back to
3.3.x until 4.2.0 is more readily available.
Aren't you glad you asked? :-)
--Jay++
-----------------------------------------------------------------------------
Jay A Estabrook Alpha Engineering - LINUX Project
Compaq Computer Corp. - MRO1-2/K15 (508) 467-2080
200 Forest Street, Marlboro MA 01752 Jay.Estabrook@compaq.com
-----------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: