Memory management bug

Ok, the BUG() hit in get_pmd_slow:

pmd_t *
get_pmd_slow(pgd_t *pgd, unsigned long offset)

{
        pmd_t *pmd;
        int i;

        pmd = (pmd_t *) __get_free_pages(GFP_KERNEL,2);
        if (pgd_none(*pgd)) {
                if (pmd) {
                        for (i = 0; i < PTRS_PER_PMD; i++)
                                pmd_clear(pmd+i);
                        pgd_set(pgd, pmd);
                        return pmd + offset;
                }
                BUG();  /* <--- this one hit */
                pmd = (pmd_t *) get_bad_pmd_table();
                pgd_set(pgd, pmd);
                return NULL;
        }
        free_pages((unsigned long)pmd,2);
        if (pgd_bad(*pgd))
                BUG();
        return (pmd_t *) pgd_page(*pgd) + offset;
}

The allocation of 4 consecutive pages for the page middle directory failed. This caused empty_bad_pmd_table to be used and clear_page_tables inserted it to the pmd quicklist. The important question is: why did __get_free_pages fail?

blue skies,
Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: [email protected]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

You really need 4 pages?

There's no way to reliably get 4 consecutive pages when you're even close to being low on memory. I would suggest just failing with a NULL return here.

What is the architecture setup for this machine? I have no clue about S/390 memory management. Maybe you can modify the pmd layout?

One potential fix for this is to just make the page size bigger. Make "Linux pages" be _two_ hardware pages, and make a Linux pte contain two "hardware pte's". That way the pmd would be an order-1 allocation instead of an order-2 one. Which is statistically _much_ more likely to be around (exponential distribution).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

If they absolutely needs 4 pages for pmd pagetables due hardware constraints I'd recommend to use _four_ hardware pages for each softpage, not two.

The issue is that failing allocation at task creation (due 8k [or more] kernel stack) is trivial to handle, just have the syscall returning -ENOMEM and userspace will handle the allocation faliure gracefully. Also the parent of the servers will never fail that allocation after it's up and running (and it can try to fork childs later on).

Failing allocation of a pagetable in some case can be solved only looping (deadlock prone) or killing the task hard without giving a chance to userspace to trap the fault (even SIGKILL signal handler may need that pmd pagetable to run). So being guaranteed to be able to allocate pagetables unless the machine is truly out of memory is quite necessary "feature" IMHO.

We faced similar issues while thinking at possible ways for x86-64 pagetables, and we preferred not having to depend on the softpagesize framework in 2.4.x because it's very intrusive.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Yes.

However, it definitely is an issue of making trade-offs. Most 64-bit MMU models tend to have some flexibility in how you set up the page tables, and it may be possible to just move bits around too (ie making both the pmd and the pgd twice as large, and getting the expansion of 4 by doing two expand-by-two's, for example, if the hardware has support for doing things like that).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/