From: uaca@alumni.uv.es
To: linux-mm@kvack.org
Cc: quintela@fi.udc.es
Subject: Re: innofensive BUG and fix: area->map's size is not calculated ok
Date: Tue, 5 Dec 2000 15:02:45 +0100 [thread overview]
Message-ID: <20001205150245.A22619@pusa.informat.uv.es> (raw)
In-Reply-To: <20001130101742.A22088@pusa.informat.uv.es>; from ulisses on Thu, Nov 30, 2000 at 10:17:42AM +0100
Hi
this is an email I sent a week ago to lkml, since I've got no reply Riel
suggested me to send it here, I've also attached some more info at the end
On Thu, Nov 30, 2000 at 10:17:42AM +0100, ulisses wrote:
>
> In a 2.4 kernel, mm/page_alloc.c:free_area_init_core(), in the following
> assignement...
>
> bitmap_size = size >> i;
>
> ...makes bitmap_size be the double of the needed size, this calculum
> assumes that with a 512 byte map size the kernel is mapping 8*512= 4096 chunks
> of memory, that is: one bit of the map is used for each chunk of memory,
> and that's not true.
>
> Really one bit of area->map is used to map two chunks of memory, so in the
> example above an area->map of just 256 bytes is really needed, the other 256
> bytes are _never accessed_.
>
> So the righ thing would be to do is:
>
> bitmap_size = size >> (i+1);
>
>
> also I tested it and it works ok, so I believe I'm right...
>
>
> Please CC: your replies to (I'm not subscribed to this list)
>
> Ulisses Alonso Camaro <uaca@NOSPAM.alumni.uv.es>
>
> PD: my nick on #kernelnewbies is despistao
an easy to understand indicator to see that I am right is to see
(for instance) how a page index of area->map is calculated,
in __free_pages_ok() we can see the following:
page_idx = page - base;
index = page_idx >> (1 + order);
Imagine the order is 0, that is a continious block of PAGE_SIZE size,
we still shift page_idx one bit, that is two blocks of "order" size are
maped in each bit of area->map
you can also see that MARK_USED macro also makes this shift
Please CC: your replies to (I'm not subscribed to this list)
Ulisses Alonso Camaro <uaca@NOSPAM.alumni.uv.es>
PD: my nick on #kernelnewbies is despistao
Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers." Pablo Picasso
---> Visita http://www.valux.org/ para saber acerca de la <---
---> Asociacion Valenciana de Usuarios de Linux <---
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
parent reply other threads:[~2000-12-05 14:02 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20001130101742.A22088@pusa.informat.uv.es>]
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=20001205150245.A22619@pusa.informat.uv.es \
--to=uaca@alumni.uv.es \
--cc=linux-mm@kvack.org \
--cc=quintela@fi.udc.es \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox