Re: serious memory leak in hurd

[Samuel Thibault]

Da Zheng, le Sat 12 Jun 2010 21:23:51 +0800, a écrit :
> On 10-6-12 下午7:58, Samuel Thibault wrote:
> > Da Zheng, le Sat 12 Jun 2010 19:46:49 +0800, a écrit :
> >> Here is what I did. I scp a big file from the Hurd (in the virtual 
> >> machine) to
> >> the host OS. I check the memory statics with vmstat constantly. After a 
> >> while, I
> >> can see the physical memory in the hurd system is exhausted and then a 
> >> defpager
> >> error message. see the picture http://a.imagehost.org/view/0824/Picture_2.
> > 
> > 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 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.

> > 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

Samuel