All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: "Samium Gromoff" <_deepfire@mail.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.5 and lowmemory boxens
Date: 18 Oct 2002 13:35:04 +0200	[thread overview]
Message-ID: <m37kggyo7r.fsf@averell.firstfloor.org> (raw)
In-Reply-To: <E182V29-000Pfa-00@f15.mail.ru>

"Samium Gromoff" <_deepfire@mail.ru> writes:

>    first: i`ve successfully ran 2.5.43 on a 386sx20/4M ram notebook.
> 
>  the one problem was the ppp over serial not working, but i suspect
>  that it just needs to be recompiled with 2.5 headers (am i right?).
> 
>  the other was, well, the fact that ultra-stripped 2.5.43
>  still used 200k more memory than 2.4.19, and thats despite it was
>  compiled with -Os instead of -O2.
>  actually it was 2000k free with 2.4 vs 1800k  free with 2.5
> 
>  i know Rik had plans of some ultra bloody embedded/lowmem
>  changes for such cases. i`d like to hear about things in the area :)

I would start with clamping down all the hash tables. A lot of code
does something like: 

        mempages *= sizeof(struct list_head);
        for (order = 0; ((1UL << order) << PAGE_SHIFT) < mempages; order++)
                ;

        do {
                unsigned long tmp;

                nr_hash = (1UL << order) * PAGE_SIZE /
                        sizeof(struct list_head);
                d_hash_mask = (nr_hash - 1);

                tmp = nr_hash;
                d_hash_shift = 0;
                while ((tmp >>= 1UL) != 0UL)
                        d_hash_shift++;

                dentry_hashtable = (struct list_head *)
                        __get_free_pages(GFP_ATOMIC, order);
        } while (dentry_hashtable == NULL && --order >= 0);

which usually results in too big hash tables.

Unfortunately this isn't a common function that can be tuned centrally
(it *really* should be). But you could grep for hash and change them
all to only use a single page or even less. 

More text size could be saved by going through the header files and
uninlining bigger functions.

When you have lots of daemons that hang around in select() or poll()
then it's possible to save 8K for each of them by applying a patch
that allocates data for small select on the stack.

Also Linux by default doesn't use the area in 640k-1MB. If you know
the exact mappings there on your box or trust your e820 table then
you can change setup.c to use the free areas in there.

-Andi

  reply	other threads:[~2002-10-18 11:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-18 11:11 2.5 and lowmemory boxens Samium Gromoff
2002-10-18 11:35 ` Andi Kleen [this message]
2002-10-18 16:50   ` Andrew Morton
2002-10-18 21:46     ` Daniel Phillips
2002-10-18 22:37       ` Andrew Morton
2002-10-18 11:54 ` jbradford
2002-10-18 14:21   ` Russell King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m37kggyo7r.fsf@averell.firstfloor.org \
    --to=ak@muc.de \
    --cc=_deepfire@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.