Re: Strange interrupt behaviour

Gerard Roudier (groudier@club-internet.fr)
Sun, 12 Jul 1998 19:10:52 +0200 (MET DST)


On Sat, 11 Jul 1998, Linus Torvalds wrote:

> On Sun, 12 Jul 1998 ak@muc.de wrote:

[ ... ]

> Yes, I do know that the x86 actually has 4kB pages, but that's a small
> hardware detail. The Linux memory management could _trivially_ be changed
> to think that page tables have 512 entries of 8 bytes each (mapping 8kB
> per entry) instead of 1024 entries of 4 bytes each.
>
> The advantage would be bigger clusters for page-in, and swapout, and
> generally better performance (one page fault would fault in two of our
> current small pages).
>
> However, the big downside (apart from slightly bigger memory use) is that
> it impacts user level (mmap would also be 8kB-constrained). And that is
> probably unacceptable.

If we were happy using 4K pages on a 2 MB machine, we shouldn't be that
sad to use 64K _logical_ pages on a 32 MB machine.
When Intel has unfortunately invented the 386 architecture, they probably
did'nt imagine their bogosity will one day have to deal with hundreds of
MB of memory. So, the 4K page on ia32 is probably a very sub-optimal
page size.

> So the sligtly uglier version of this is to do all page allocations as 8kB
> chunks, and then the memory management layer has its own "sub-buddy" to
> split a 8kB page into two hardware pages. The sparc already does something
> like this for some of its page table pages, which are partial pages rather
> than a full page like on a normal architecture. It wouldn't be too painful
> to do this generically.
>
> However, I'd prefer to still try out some other ways of handling this. For
> example, "__get_free_pages()" currently only re-tries once. It shouldn't
> be hard to make it re-try a few more times, and it might well be enough to
> make the problem go away.

This has been proven to be broken, at least with the current VM/MM stuff.
Trying hard to get 2 contiguous pages leads very often to throw away more
that half the available cached objects, regardless the actual memory size
being used.

> 2.1.x is not going to be usable on 4MB machines. I didn't even have to

Hmmm ... Is it really usable on a 512MB machines? ;-)
It seems that there are some breakages that cannot be cured by increasing
the memory size.

> change the kernel for that - the distributions have made that abundantly
> clear anyway. It may be that we will simply say that "hey, if you have a
> 486-8MB, then 2.0.x works better, and the new features of 2.1.x aren't
> worth it for you".

I have a low-end 64 MB machine and I am not sure 2.1.x is able to work for
me.

> One of the reasons I disliked Minix back when I used it was that it was
> designed for a machine that was no longer current. I want new versions of
> Linux to be optimized for new hardware, and I also think that it should be
> acceptable to tell people that they can still use old kernel versions. I
> got reports of people using Linux-1.0.x long into the 2.1.x development
> tree, and they may still be out there for all I know. And to some degree
> it is actually _good_ that people decide that they don't need/want to
> upgrade to newer systems if their old setup is good enough for them.

BTW, the 8K kernel stack is, in my opinion, broken by design with a 4K
actual page size. Having to cross fingers for forking a process or having
to pay for throwing away most of cached objects is not the way to go.
Using cluster of pages will fix this definitely.

atomic_inc(sarcasm_mode)

Are you waiting for the BSD people or BG to implement this prior to
taking decision? ;-)

atomic_dec(sarcasm_mode)

Regards,
Gerard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html