kwrohrer@enteract.com writes:
> The worst I experienced was a few seconds of pause...and while the
> pauses go away, I lose more time to excess paging than I gain in
> missing pauses. Compiles sound like kernel builds back in the days
> I had only 4M of RAM...
>
OK, it seems like your kernel was recovering from blockings.
Considering that, you in fact didn't have much trouble (maybe you have
enough RAM).
My machine would happily stay locked for about half an hour (after I
killed my xdm session!). In fact I'm working remotely *right now*, so
if it blocks *now*, you'll never get this mail. :)
And what is a second or two of swapping compared to killed XEmacs,
Netscape, xterms and all foreground jobs, and big pause before
regaining control?
But, I'm completely aware that I did not find a solution but a
workaround, well, just to let me work in peace.
Yesterday, I did somewhat different hack and I'm waiting to see the
results of it.
> Does your patch (or kswapd) do anything to pick pages to evict which
> will result in blocks of the desired size being freed? Or does it just
> throw out pages until luck results in enough larger chunks being free?
> I suspect the latter...and that this is resulting in more excess free
> memory than anything I'd echo into /proc/sys/vm/freepages...
No, it just throws pages out until enough of big chunks get freed. So
it's pure luck when it will happen. But if you have 2MB of free RAM
(just swapped some pages out), wouldn't it be correct to assume that
you have at least two free 16KB chunks?
Unfortunately v2.1.x Linux kernel doesn't behave very good, and I
don't like it very much. It can be easy solved if you buy 128MB of
RAM, but... :)
> Even with the patch in place, things like the sound driver or the
> floppy driver may not be able to allocate their buffers because all
> your patch guarantees is that half the miniumum free pages is free
> in blocks of order>=2...which could mean all order=2 in practice.
> At least you're not paging stuff out until half of all the free
> memory is in order>=2 chunks, I hope...
No I wait for min_free_pages / 2 pages in order >=2 chunks.
And patch was written only to prevent network blockups, and NOTHING
ELSE. Unfortunately...
I also have insmod sound in my /etc/init.d/local ;)
Even if I wont hear a sound before next reboot.
>
> But we need a mechanism to direct kerneld to create the large
> contiguous chunks we need, perhaps one array for ISA-DMA-capable
> slabs of each order, and another array for slabs of each order
> which need no special location. So long as free space isn't
> horribly fragmented by locked pages, it should be able to blit
> allocated buddies of free pages into other free pages (or swap
> them out to the disk), directly promoting free slabs of modest
> order into free slabs of higher order until it gets what it
> needs.
>
Yes, I agree with you completely. The only problem is: who's gonna
write it?
As I said, I just started digging the code and learning things.
And my time is very limited, 'cause I have lot of other things to
do. Well, it's everybody problem, after all. :)
BTW, the only place where such functionality would be efficient is in
the kernel, I believe. I'm not completely sure that kerneld would be
up to that job.
> Does this sound like a more reasonable and direct solution?
> Is there something I'm missing? I haven't read the vm code
> very heavily yet, so I could be misconstruing CAN_DMA() in
> mm/page_alloc.c, but that's a side issue, as is nailing down
> the pages in the free slabs you're trying to inflate...
>
> Keith
>
> [Please feel free to forward this to linux-kernel; I'd have done
> so myself if it didn't contain a large chunk of private email.]
>
>
[mailed and posted]
Regards,
--
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
A good way to deal with predators is to taste terrible.