1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Thanks David for the clear answers.... I'll investigate further. As for |
5 |
the rest of the PC.... running great with extra RAM ~ it's just UT2004 I |
6 |
have discovered to have an issue here. |
7 |
|
8 |
The 2/2 is what I'm running with at the moment ... seems to be fine. |
9 |
|
10 |
Thanks again, |
11 |
Ralph |
12 |
|
13 |
David Klempner wrote: |
14 |
> * Ralph Slooten <axllent@×××××.com> [2006-06-19 00:25]: |
15 |
>> David Klempner wrote: |
16 |
>> > Note that without doing *anything*, with a normal 3G/1G split, you'll |
17 |
>>> actually get 896M. Recent kernels added in a config option to have a |
18 |
>>> 2.75G/1.25G split, which solves this problem; it makes sense to use that |
19 |
>>> if you have 1G of RAM. |
20 |
>> This option must be really new because I don't have it. I have two 3/1 |
21 |
>> options, a 2/2 option and a 1/3 option. Either way, I'm now using 2GB. |
22 |
> |
23 |
> It's one of the two "3/1" options; one of them is a PAGE_OFFSET of |
24 |
> 0xC0000000 (3G) and the other is 0xB0000000 (2.75G); the latter is |
25 |
> suggested for someone using 1GB. (I was making that change myself by |
26 |
> hand until they added that option.) |
27 |
> |
28 |
> In fact, the 2G option is slightly lower than 2G, which is why it works |
29 |
> with 2G of RAM. |
30 |
> |
31 |
>> Maybe this is the case, I'm not sure. For testing some other software I |
32 |
>> upgraded to 2.16.6.16 2 weeks ago (when I still had 1GB) which resulted |
33 |
>> in the same problem. I then went back to the previous-compiled 2.6.16.5 |
34 |
>> version which worked flawlessly. It is only now that I have actually |
35 |
>> rebuilt the 2.6.16.5 kernel (due to RAM upgrade) and am having the same |
36 |
>> problem. The NVidial kernel and glx (to be sure) were also rebuilt. |
37 |
>> |
38 |
>> I did a bit of testing last night before I went to bed and it seems that |
39 |
>> no matter what options I use in the kernel I'm getting bad performance |
40 |
>> now from the graphics card. It still gets > 4000 fps with glxgears |
41 |
>> though, so I'm not 100% sure it is the graphics card. |
42 |
>> |
43 |
>> The question I was meaning to ask is what the ideal kernel settings |
44 |
>> should be for 2GB of RAM... from there I'll look for other explanations |
45 |
>> why the 3d isn't performing well. |
46 |
> |
47 |
> Do you have performance problems with any other applications? It |
48 |
> wouldn't surprise me too much if it's some random library issue that |
49 |
> specifically affects that game. |
50 |
> |
51 |
>> Should I use 2/2 *and* highmem, or just 2/2 ? You suggest the highmem |
52 |
>> does very little, but it's there for a valid reason I take it. |
53 |
> |
54 |
> If you're doing 2/2, then don't bother with highmem. Without highmem, |
55 |
> the kernel maps all of physical memory into its address space; this is |
56 |
> naive and fast, but it means that normal processes don't get use of that |
57 |
> space. This isn't a problem for most applications, but there are a few |
58 |
> that expect the extra address space to be available. A direct result of |
59 |
> the 2/2 split is that no single process can, even in theory, (directly) |
60 |
> use more than 2G of RAM, because it can't even *address* more than 2G. |
61 |
> |
62 |
> This would be a more noticeable issue if you had 3G of RAM and did the |
63 |
> 1/3 split; at that point, no process could use more than 1G. I've seen |
64 |
> long running processes (for example, firefox after a month with several |
65 |
> dozen open tabs) use more than that. |
66 |
> |
67 |
> Highmem adds an extra layer of indirection to solve this problem; it's |
68 |
> slightly slower (but, I understand, the cost is minimal) but lets you |
69 |
> have your address space back while still being able to use all of your |
70 |
> RAM. |
71 |
> |
72 |
> My suggestion is to use 3/1 with highmem. If you want, you could also |
73 |
> use 2/2 without highmem; it would probably be just slightly faster, but |
74 |
> could break stuff. Using 2/2 with highmem is (I think) pointless. |
75 |
-----BEGIN PGP SIGNATURE----- |
76 |
Version: GnuPG v1.4.0 (MingW32) |
77 |
|
78 |
iD8DBQFEllAACt0ZF9kLPvYRAja0AJ4gKhWbGw9uQAWVnsqj/ii9xvPm3wCfZVYE |
79 |
N18blB/cTNxITFmcNMEC+Jw= |
80 |
=VBJE |
81 |
-----END PGP SIGNATURE----- |
82 |
-- |
83 |
gentoo-user@g.o mailing list |