There is a thread in laptops with same problem but KEES74 solved it by changing distro.

HPdesktop running the latest PCLinuxOS. It has 2Gb ram and pentium 4 and it spends 5 minutes or more just swapping stuff in and out. Whilst this is going on the computer locks up. One thing that brings it on is attempting to save, the window that comes up takes 5 minutes or more to be useable.

Can anybody tell me what the process "khugepaged" (it runs under "kthreadd") does as it is running a lot?

"kswapd0" is also running far more that I would normally expect.

You cannot do any thing while it swaps stuff around. I was running MiniMe2008 on dual amd processor and it never had this sort of problem

Let's see the output of "grep -i huge /proc/meminfo"

May be some bad app or data issue. I might suggest a test. Install some 32 bit OS on that and see what it does with a stock install. Like any of the latest big name ones. Fedora, Ubuntu or OpenSuse (really most of the top 10 at distrowatch)

See if they behave like this.

I don't think memory is the issue. I guess it can't hurt to run memtest.

Could turn off swap to see what is going on maybe.


"
64 Transparent Hugepage Support maximizes the usefulness of free memory
65 if compared to the reservation approach of hugetlbfs by allowing all
66 unused memory to be used as cache or other movable (or even unmovable
67 entities). It doesn't require reservation to prevent hugepage
68 allocation failures to be noticeable from userland. It allows paging
69 and all other advanced VM features to be available on the
70 hugepages. It requires no modifications for applications to take
71 advantage of it.
72
73 Applications however can be further optimized to take advantage of
74 this feature, like for example they've been optimized before to avoid
75 a flood of mmap system calls for every malloc(4k). Optimizing userland
76 is by far not mandatory and khugepaged already can take care of long
77 lived page allocations even for hugepage unaware applications that
78 deals with large amounts of memory."


From http://www.mjmwired.net/kernel/Docum.../transhuge.txt

The PC dual boots, Kubuntu 8.04 and has no problem with swap with that OS. I have another much older computer with only 750M memory that also has PCLinuxOS (as well as Kubuntu 6.04) on it and it hangs as well but I put that down to a fault. I am using PCLinuxOS as it has a good working version of Avidemux, with Kubuntu 8.04 it looses sound, a known problem that doesn't seem to have been fixed. I tried later Kubuntu releases but they either wouldn't work or were so bad that I couldn't use.


[root@%%%%%%%% ~]# grep -i huge /proc/meminfo
AnonHugePages: 319488 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 4096 kB

As best as I can tell, as you cannot just change to Htop or Sysinfo to check, there can be 500M of unused memory when the thing locks up.

Can Hugepagead just be removed?

Don't know - however I'm a "why not try" person. I'd try to kill it - if it all goes to hell you can always reboot.

Maybe first try this and see if it helps

This is third attempt to reply. First time the system lost the keboard and mouse. Next time Opera crashed, surprisingly it didn't come back where it had been.

I tried madvise ... it didn't seem to do anything, I was using about 900MB memory so I loaded up as many programs and browser tabs as I could and had about 1.6 Gb of memory used, still 500Mb free but problems started. tried madvise .. again still no apparent affect. Did some more work and still had the problem. However memory use went down to 1.5Gb and 350MB of swap used. I changed nice of hugepaged fron 19 to -15 but didn't seem to make any difference.

You can not kill hugepaged. I tried to find out where it is started but no luck. So I started to reply and suddenly I had no keyboard or mouse. Cursor and mouse were gone and I couldn't find a way to get them back. Had to switch power off and restart.

On restart turned off swap, still using 1.5 Gb memory but straight away it was slow changing from window to window. Not quite as bad starting the "download to" dialogue. So went to redo this post and was about this far, went to another window to check memory use and Opera just wasn't there when I returned to its window. So restarted it again but it didn't come back to this tab which is most unusual.

So with no swap and 500Mb free memory it is still very slow to stationary and the hard disk is having a hard time. This time I have composed this in text editor and a good idea as Opera has crashed again. Was switching window to check on how much memory was used and going back to Opera there was much thrashing of hard drive and then things went smoothly. That's when I realised opera had gone again.

The problem cannot be swap as there is none and 500Mb of memory free there should be no problem. So it has to be hugepaged, something I haven't even thought of or possibly I need to allocate more memory to video. Will try that later. Now to save this and try to restart Opera and copy & post this reply. Second restart of Opera later and hopefully it will go this time.

It almost seems to be that it runs out of memory even though there is 500MB spare.

O.K., try turning it off altogether.

Tried again today without any swap and reduced the number of window/tabs open in Opera but with a few other thing open so memory still using about 1.5 Gb. Opera wasn't crashing but it wasn't locking up either but very slow at times and the hard disk was getting a workout.

So tried the "echo never ... definitely has made it better. The open download dialog is still slow but faster, doesn't lock up for 5 mins and the hard disk isn't getting thrashed. Changing windows is much better/faster and again without the hard disk workout. It improved over about 1/4 hour presumably as the stuff in hugepaged was replaced in proper memory.

Next time I boot I'll change the amount of video memory. When the very old machine gets fired up again will try the same thing on it.

Not sure if the madvise .. was very helpful.

Thanks syg000, will have to investigate more about "hugepage"

I'm guessing you have a (very) slow hard-disk.

Turn the swap back on, it's a "safety valve". Maybe also try "never" to the defrag sysctl - if that works you may still get the benefits of transparent huge pages without the grief.

O.K. have tried various things.

Turned swap back on with 1.6Gb memory used and it crashed Opera. It is not only Opera that sufferas FireFox comes up with messages that say "a script has stopped executing" but you can not either get to the messages or turn tham off.

Hard drive 'Very' slow, not really, it is SATA and hdparm gives 64Mb/s as read speed. I have considered slowing it a bit so that it is not as noisy.

There isn't any way to change video memory.

/proc/meminfo shows that hugepaged has 314Mb allocated but none used, currently I have not done the "never" and since starting it has gone from 314Mb at boottime to 421Mb now 3 hr later. Currently also have swapon and as long as I don't need to use swap it goes OK. In fact it seems much faster with swapoff.

I notice that vmalloc is set to 256Mb but only uses 32Mb, it is set in kernel parameters at boot. Have tried to take it down to 128Mb or 64Mb but it insists on running 256Mb and leaving most of it unused.

This is listing of all of /proc/meminfo

MemTotal: 2065384 kB
MemFree: 315868 kB
Buffers: 13004 kB
Cached: 635768 kB
SwapCached: 0 kB
Active: 1067136 kB
Inactive: 609224 kB
Active(anon): 851480 kB
Inactive(anon): 443696 kB
Active(file): 215656 kB
Inactive(file): 165528 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 1322820 kB
HighFree: 136684 kB
LowTotal: 742564 kB
LowFree: 179184 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 3184 kB
Writeback: 0 kB
AnonPages: 1027724 kB
Mapped: 132780 kB
Shmem: 267588 kB
Slab: 36392 kB
SReclaimable: 20520 kB
SUnreclaim: 15872 kB
KernelStack: 2616 kB
PageTables: 6812 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1032692 kB
Committed_AS: 2150352 kB
VmallocTotal: 262144 kB
VmallocUsed: 31120 kB
VmallocChunk: 215760 kB
HardwareCorrupted: 0 kB
AnonHugePages: 446464 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 4096 kB
DirectMap4k: 24568 kB
DirectMap4M: 741376 kB

This to me says that there is 446464 kb of hugepaged which is empty, plus 215760 kb vmalloc wasted which agrees with the 2065384 kb memory and 315868 kb free (at top) and both say I am using a just over gigabyte, htop 1078kb and sysguard 1.1Gb

2065384 total Memory

315868 free
215760 vmalloc
446464 hugepaged
----------------
978092 total unused
plus
1078000 used
------------
2056092 total (near enough 2Gb)

That to me is why I am having problems as soon as the machine uses more than 1.6Gb memory, over 650Mb is wasted. Is there any way to turn off hugepaged at boot and also make vmalloc either giveup unused or start with only 64Mb?

A lot of this is not making a lot of sense. I found an old 32-bit system (with F16 on it, so current kernels), but it only has a Gig of memory so it's not using PAE bounce buffers (if that matters - who knows).
Seems to run fine.

I would try to disable swap, and use zcache (in staging drivers) instead. I've had lots of issues of this type and I think this helps. You may also want to try a different I/O scheduler, you can change them on a running system.

If the system hangs or crashes check /var/log/messages and syslog, and post anything unusual at the time of the crash.

I think it may be due to the kernel. PCLinuxOS always used to have its own kernels *-*-*-tex. This is 2.6.38.8-pclos3.bfs.
From memory the installer selected which version. The CPU is P4-3000Mhz (dual core) maybe I should switch to the plain i686 Linux kernel. I tried to fire up the old machine with PCLinuxOS on to compare but it wouldn't boot. Some problem with ext2fsck not having permission to read disk. It was very much the same, OK till it needed to use swap and then it locked up for 5 mins or more. Originally it had 500Mb memory but I put in another 250Mb (750Mb total) which helped up to the swap point .

Kernel versions: There is a 2.6.31.12-pclos1, 2.6.32.24-pclos1 in same versions as below, 2.6.33.7-pclos6 in same versions as below and 2.6.38.8-pclos1 also in same version as below.

Current kernel description is:

i686 linux kernel with the BFS scheduler

This kernel package contains the Linux 2.6.38.8-pclos3.bfs kernel patched with the BFS scheduler from Con
Kolivas. It is optimised for i686 CPUs, supports up to 4GB of system memory (highmem enabled). The
kernel timer interrupt is set to 1000 HZ, it defaults to using the 'BFS' scheduler, 'SMP' is enabled
and is compiled with kernel preemption enabled.

Alternatives are:

i686 Linux kernel
This kernel package contains the Linux 2.6.38.8-pclos kernel. It is optimised for i686 CPUs,
supports up to 4GB of system memory (highmem enabled). The kernel timer interrupt is set
to 1000 HZ. It defaults to using the 'CFQ' scheduler, 'SMP' is enabled and is compiled with
voluntary kernel preemption enabled.

AMD64/Opteron (K8) optimised linux kernel for x86 arch
This kernel package contains a AMD64/Opteron (K8) optimised Linux 2.6.38.8-pclos3.a64 kernel compiled for
the x86 arch. It is compiled with kernel optimisations specifically for AMD 'K8' series CPUs, 'SMP'
is enabled, it supports up to 4GB of system memory and the kernel timer interrupt is set to 1000 HZ.
It defaults to using the 'CFQ' scheduler and is compiled with voluntary kernel preemption enabled.

i686 server Linux kernel (pae enabled)
This kernel package contains a PAE enabled Linux 2.6.38.8-pclos3.pae kernel. It is optimised for i686 CPUs,
supports up to 64GB of high memory. The kernel timer interrupt is set to 100 HZ, defaults to using
the 'CFQ' scheduler, 'SMP' is enabled and kernel preemption is disabled. This kernel requires a CPU
with Physical Address Extensions (PAE).

i686 linux kernel pae bfs scheduler
This kernel package contains the Linux 2.6.38.8-pclos3.pae.bfs kernel patched with the BFS scheduler from Con
Kolivas. It is optimised for i686 CPUs, supports up to 64GB of system memory (highmem enabled). The
kernel timer interrupt is set to 1000 HZ, it defaults to using the 'BFS' scheduler, 'SMP' is enabled
and is compiled with kernel preemption enabled. This kernel requires a CPU with Physical Address
Extensions (PAE).

Todays update.

Apology first, I changed the wrong grub line. So changed the correct one and it only uses 64Mb vmalloc.

Next after rebooting following that change I put in the echo never> ... and the hugepaged memory was only 24576Kb way down on the 442Mb I was getting.

Turned off swap and it has been very responsive and no disk thrashing but I have been using only about 1Gb of Ram but despite that I have only 200M free Ram according to /proc/meminfo.

I have installed the latest 2.6.38.8-pclos3 kernel rather than the .bfs version. From my somewhat dodgy memory it would not install other than the .bfs version before and it seems to have fixed the problem. I still turn off hugepages. Perhaps I should try the 2.6.38.8-pclos3.bfs version to see if it is still has the problem but why "fix" what is working.

I have yet to check/update/change the kernel version on the old machine that has the same problem.

It would seem that the BFS scheduling part of kernel is the problem.