SliTaz Forum
You are not logged in.
Pages: 1
Can anyone give me a hint on how Slitaz would handle 8 GB of RAM ?
I understand Slitaz is 32 bits, will it support 64 bits in the foreseeable future ?
with 8 GB, can I hope that some amount (1or 1.5 GB) will be used my the graphic card if it can do that, then the rest would be split between / (frugal or usb install) , tmpfs, and the "ram" in the classical sense of the word, (for execution of processes), so that most of the 8GB could be used and it is making sense to get that much memory ?
Thanks
Offline
For 32-bit, it would need to be PAE.
Offline
It should handle 8GB RAM just fine and will at most probably end up using max 1,6GB after you install everything you need on it (including compiler). I also don't think you'll need more than 512MB for Graphics - I only use 32MB with SliTaz. The rest should be free for the system to use as needed.
Offline
Tx
What is PAE ?
Offline
i am realizing my question carries some ambiguity.
Being 32 bits, will the system be able to handle 4GB of Ram PLUS the space needed for / if i use an install with / in Ram, PLUS, a tmpfs ?
In other words, will all these be in different address spaces which allows all of them to use together more than 4GB ?
The underlying question being, is it worth to buy more than 4GB, (or not since the 4-8 GB part is not in the addressable space anyway) ?
Tx
Offline
what is PAE Kernel?
https://en.wikipedia.org/wiki/Physical_Address_Extension
Offline
ok this is what i found there:
Linux
The Linux kernel includes full PAE mode support starting with version 2.3.23,[7] enabling access of up to 64 GB of memory on 32-bit machines. A PAE-enabled Linux kernel requires that the CPU also support PAE. As of 2009,[8] some common Linux distributions have started to use a PAE-enabled kernel as the distribution-specific default[8] because it adds the NX bit. [9]
it also says
The Linux kernel supports PAE as a build option and most major distributions provide a PAE kernel either as the default or as an option
So...
Does Slitaz support PAE ?
Offline
it is the question, what you mean with does slitaz support PAE - if you mean, is the kernel of slitaz a PAE kernel - the answer is no.
But you can build your own PAE Kernel if you want, because SliTAz uses Kernel 2.6.37
as I remember you have to set CONFIG_HIGHMEM64G=y in the kernel config - the rest is in this guide
http://doc.slitaz.org/en:guides:kernel
Offline
I am guessing that some day i will have to go into learning how to do that ...
thanks for your answer
Offline
one more question on that one....
Will or should a PAE-enabled kernel be able to run any 32 bit slitaz package ? and should I expecte everything to work flawlessly.
Or should slitaz packages specifically be recompiled for it ?
Thanks
Offline
Let me explain why i ask.
If PAE enabled kernel is able, in theory, to run all 32 bit packages unchanged, THEN,
Instead of creating a 64 bit version why not have "only" an additional PAE version ?
This way the work of creating and maintaining packages would be divided by 2
plus, i have been struggling on a 64bit ubuntu like with wine 
so that i am starting to wonder why a 64bits version would be needed, if a PAE version would do the job....
And there will be a long time before we exhaust the 64GB that can be addressed with a PAE kernel.
Any thought from the developers ?
Offline
I am not a developer, but I think you are right
I use on my Audio and Video Machine AV-Linux - and AV Linux just provides a normal kernel and a pae-kernel
There exists also another AV Distro - 64Studio with 64 bit Kernel and 32 bit Kernel - I was using it before, but AV-Linux is much better (lets say was, because I did not test their distri for now 2 years
I think, thus we have no paid devs, its much better to concentrate on 32 bit with pae and on arm
maybe I will try to make a pae kernel in the next days...
Offline
I'm afraid that not all processors are PAE compatible, some old processors will bring you this message:
This kernel requires the following features not present on the CPU:
pae
Unable to boot - please use a kernel appropriate for your CPU.
Among them are: pre-Pentium Pro (including Pentium MMX), Celeron M and 400 Mhz Pentium M processors, AMD K6 and earlier, VIA C3 and earlier, and Geode GX and LX.
Offline
thats clear - nobody wants slitaz with pae - just as post-install or as a special flavor
see AVLinux http://www.bandshed.net/AVLinux.html
Offline
Honestly, it's not a viable option for 32bit systems since even Windows needs a hack for it. Hell, most 32bit applications won't be able to use more than the first 4GB anyway...
It makes more sense to have PAE for 64bit and ARM kernel versions instead.
Offline
hence, stick with 32bit slitaz + PAE slitaz supporting up to 64GB ram + ARM version
for which we need only one set of packages, 32 bits packages, which will run on 386 and PAE.
(Furthermore, a number of packages WOULD create problems of some sort to run on a 64 bits plateform
eg: Wine, Skype, which I consider both as being mandatory for a decent desktop).
So to our dearest friends of the developping team, time to shift focus away from a pure 64 bits Slitaz, what do you think ?
The time that would be saved, in terms of systems developpment, applications availability, support on the forum... would probably be worth it, right ? and we could use the saved time on QUALITY delivery: more testing, more beta testing, better documentation, etc. which would fuel a virtual loop, hopefully....
Offline
Some level of support is needed for 64bit because a form of PAE is built into it and we all know that ARM was designed for systems with large amount of RAM so it's a logical given.
What however isn't logical is adding PAE to a 32bit system where the majority of applications designed for it WON'T USE more than 4Gb because they weren't designed to use PAE's 36bit addresses. That why Windows doesn't bother with it and warn about it's instability - not to even mention the LARGE amount of laptops, netbooks and older systems that would be excluded by this move. If you haven't noticed that's most of our userbase.
We have better optimizations to make to the kernel than something most of our systems and applications aren't designed to use.
Offline
As real as they are, I do not see how the technical arguments I read here relate to the issues I raised, which really are functionalities, support, and compatibilities issues.
Offline
I do see a compatiblity issue on my own system:
[c]$ cat cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 9
model name : Intel(R) Pentium(R) M processor 1200MHz
stepping : 5
cpu MHz : 1196.111
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr
pge mca cmov clflush dts acpi mmx fxsr sse sse2 tm pbe up bts est tm2
bogomips : 2392.22
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:[/c]
Offline
Does anyone know if there has been any progress in developing a version of Slitaz that can address >4Gb of RAM?
There seem to be indications that some people are making progress with a 32-bit version with PAE support (http://forum.slitaz.org/topic/slitaz-kernel-performance-and-scheduling-options/page/2), and also indications that 64-bit will be supported in SliTaz 5.0 (http://roadmap.slitaz.org/). Does anyone know when we might be able to get our hands on either to play with? :¬)
I love the fact that SliTaz runs like a train on my old Dell Latitude D600, and I would never want to lose that performance & compatibility with older hardware. However, I am also seriously thinking of using it as the default OS on my main PC, but I would need to use all the available memory (particularly as I want to use it as a VirtualBox host).
Offline
I have successfully compiled a kernel with PAE but have not used it very much (though i have not had any problem with it). I am really busy on other things by these days.
At least we know this is feasible.
Offline
Pages: 1
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.58 MiB (Peak: 1.77 MiB) ]