On Thu, 2013-04-04 at 16:53 -0300, Joao Luis Meloni Assirati wrote:
> > Dear Users,
> >
> > I installed 4GByte RAM in my motherboard succesfully. In BIOS I see all
> > the
> > 4096MByte, but after booting Squeeze it show me 3,5GByte. I know I should
> > install the kernel with PAE - so I
> > installed linux-image-2.6.32-5-686-bigmem package and restart computer.
> > After it I choose this new kernel from GRUB. After loading it stuck with
> > black screen with blanking cursor on the top left side of the screen.
> >
> > What should I do?
>
> Squeeze i386 has an amd64 kernel. The command
>
> apt-cache search linux-image
>
> will show you all the possible kernels. Choose some -amd64, for example:
>
> apt-get install linux-image-2.6.32-5-amd64
>
> Then you will have a 64bit kernel and 32bit userspace, there is nothing
> wrong with this.
>
> João Luis.
Somebody already mentioned that it might not be worth the hassle to do
what ever, just to get a few bytes more. I didn't read all mails, so
excuse me if I ask something that already was mentioned.
Do you use an integrated graphics, that shares RAM with the main memory?
Without a PAE I guess the maximal available memory of the 4 GiB should
be around 3.75GB, so it might be 3.5 now, perhaps regarding to shared
RAM for a frame buffer of an integrated graphics. IOW, if you use a PAE
or x86_64 kernel the only win might be around 250 MB that regarding to
your computer usage might not be needed.
I experienced that x86_64 kernels since a long time show as less of my 4
GiB as a 32-bit non-PAE and never found out what's going wrong, but it
has got no negative side effects, even not for heavy audio productions,
a very RAM hungry usage.
Is there a reason to have a 32-bit user space instead of a 64-bit on a
64-bit architecture machine? I'm aware about some theoretical
exceptions, e.g. people who want to use 32-bit Windows VSTs on Linux
might need a 32-bit architecture, I don't know, I prefer 64-bit
architecture and guess it's a win, even without getting more accessible
memory.
IMO switching to 64-bit for kernel + user space is the best way to go
for you.
Did you monitor the swap usage? Was the swap ever touched? I planed to
buy 8 GiB first, but than decided to test 4 GiB, before I buy more RAM
and I noticed that the swap very seldom is touched.
At the moment I'm building a kernel:
KiB Swap: 4819424 total, 0 used, 4819424 free, 1837408 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10244 rocketm+ 20 0 56980 19964 4788 R 6.647 0.526 0:00.20 cc1
512 root 20 0 203084 62788 10744 S 4.985 1.655 27:48.12 X
8510 rocketm+ 20 0 461456 17512 11268 S 1.994 0.462 0:33.25
xfce4-terminal
10238 rocketm+ 20 0 13212 1672 756 S 0.332 0.044 0:00.01 make
1 root 20 0 32820 3756 1816 S 0.000 0.099 0:01.18 systemd
2 root 20 0 0 0 0 S 0.000 0.000 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.000 0.000 0:12.16
ksoftirqd/0
5 root 0 -20 0 0 0 S 0.000 0.000 0:00.00
kworker/0:0H
6 root 20 0 0 0 0 S 0.000 0.000 0:00.00
kworker/u:0
7 root 0 -20 0 0 0 S 0.000 0.000 0:00.00
kworker/u:0H
8 root rt 0 0 0 0 S 0.000 0.000 0:00.20
migration/0
9 root 20 0 0 0 0 S 0.000 0.000 0:33.51 rcu_preempt
I never read what "cached" for the swap-line does mean, but I guess
"0 used" is for "0 used" :D.
OT: "systemd", I'm not building the kernel on Debian, with Debian I
would use init, systemd isn't as worse as I feared, but it's not my
choice to use it.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1365107583.734.344.camel@archlinux
