Re: serious memory leak in hurd

[Da Zheng]

Hello,

On 10-6-13 上午7:06, Samuel Thibault wrote:
>>> Mmm, this could just be gnumach not writing back the cached data that
>> Why does gnumach need to write back the data?
> 
> Ah, sorry, you're reading the file not writing it. Anwyay, it's still
> the same issue: gnumach doesn't dare dropping it.
> 
>> the data should have been freed.
> 
> By whom?  When?
I don't know who owns and uses the memory. It's most likely that the memory is
used to store packets. I mean after the process (or the kernel) uses the memory
(i.e., the packet has been sent to the network), it should be freed by the
process and then no processes will own it, so the memory can be used by other
processes.
> 
>> I don't know which program used most memory, but the memory should
>> be considered as free after it is used, instead of being put in the
>> inactive queue.
> 
> The inactive queue is precisely memory which is "almost free" only. Mach
> doesn't directly fetch free memory from there, allocators wait for the
> pageout thread to free some memory. The problem you're facing is
> probably just a tuning issue.
A few days ago, antrik explained me what kind of memory is inactive, so as far
as I understand, pages in the inactive queue are still owned by some processes
but they are not accessed for quite a while and are candidates for pageout. Is
it correct? so pages in the inactive queue are still being used and cannot be 
freed.
> 
>>> you transfer through scp soon enough. Really, gnumach is bad at memory
>>> management without some swap to help it when it gets wrong, do give him
>>> some :)
>> I have a swap partition and in /etc/fstab, there is a line:
>> /dev/hd0s2           none            swap    sw              0       0
>> The swap should have been enabled, right?
> 
> I'd tend to guess so, but your picture says "swap size: 0"
> 
>> I tried swapon -a, and get a message:
>> swapon: /dev/hd0s2: short read 1024 reading Linux swap signature page
>> Is it an error?
> 
> It is.  Are you perhaps using the old K16 qemu image?  There is a bug
> with it, you need to fix the image size:
> 
> dd if=/dev/zero of=debian-hurd-k16-qemu.img bs=4128768 seek=519 count=1
No, I'm not using the qemu image. Hurd runs in VMWare. But I used K16 CD to
install Hurd. Can it be a problem?

Zheng Da