| 1 |
Ryan Rice posted <43FF4541.7020704@××××××.com>, excerpted below, on Fri, |
| 2 |
24 Feb 2006 12:41:21 -0500: |
| 3 |
|
| 4 |
> Does anyone have any clue where to download the bigsmp kernel for |
| 5 |
> x86_64? I can't seem to find it anywhere. I've googled it up and down |
| 6 |
> the wall. This has been the root of all my problems... |
| 7 |
|
| 8 |
OK, after googling myself, I believe you have a misunderstanding. |
| 9 |
|
| 10 |
The "big" in "bigsmp" for x86, refers to the 64G memory patches for |
| 11 |
x86-32-bit. Those aren't needed for amd64, which with its larger address |
| 12 |
space of 40 bits physical memory, 48 bits virtual memory (CPU limits, the |
| 13 |
software limit is actually the 64-bit limit of the address bit depth), |
| 14 |
allows for a full terabyte of physically addressable memory, 256 terabytes |
| 15 |
of virtual memory. |
| 16 |
|
| 17 |
By the time that's exceeded, the current 40/48-bit limit should have been |
| 18 |
itself upped. There is of course room to do so up to the full 64-bitness |
| 19 |
of the instruction set. |
| 20 |
|
| 21 |
So... unless you happen to have more than a terabyte of memory, I don't |
| 22 |
think the lack of bigsmp for amd64 is the root of your problems, after |
| 23 |
all. That also explains why you haven't found such an animal on Google. |
| 24 |
(Of course, the smp part is readily configurable as an option in the |
| 25 |
mainline kernel...) |
| 26 |
|
| 27 |
As for your problem, which IIRC was with 32 gig or more, not trying to be |
| 28 |
unsympathetic, but honestly, and I think most would agree here... would |
| 29 |
that we had such problems. The lack of effective response is simply |
| 30 |
because you've basically outclassed virtually everyone here. |
| 31 |
|
| 32 |
Suggestion: If you are dealing with that sort of memory, the kernel team, |
| 33 |
which has been targeting upscaled deployments, may be quite interested in |
| 34 |
your problems. The relative number of deployments on the arch in that |
| 35 |
range means there will be significantly more bugs, simply because there |
| 36 |
haven't been enough deployments to find them all. Maybe they can be of |
| 37 |
help, particularly if you are willing to test stuff for them. |
| 38 |
|
| 39 |
Also, FWIW, if you have that sort of money dedicated to a machine, |
| 40 |
consider hiring someone skilled in huge memory and kernel issues, at least |
| 41 |
on a temporary consulting basis. One doesn't invest that sort of money to |
| 42 |
run a desktop, and some consulting to get the system up and running at |
| 43 |
peak efficiency (and showing you the basics) could be well worth it in |
| 44 |
terms of increasing that efficiency. At that level, tweaking for the |
| 45 |
application at hand and type of usage expected can make a pretty big |
| 46 |
difference, I'm told. |
| 47 |
|
| 48 |
-- |
| 49 |
Duncan - List replies preferred. No HTML msgs. |
| 50 |
"Every nonfree program has a lord, a master -- |
| 51 |
and if you use the program, he is your master." Richard Stallman in |
| 52 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 53 |
|
| 54 |
|
| 55 |
-- |
| 56 |
gentoo-amd64@g.o mailing list |
Archives