lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Where is memory handed out?
Date
From the top....

ACPI biosen issue a series of reports describing memory. Each report
describes one region--it's address, length, and type. The smap= option
allows the user to specify their own set of reports, as well as control
certain parameters of the processing.

In order to simplify processing, I have been working on generating a
resource tree of the memory pages. This will allow the available pages to
be read off directly. It also is a relatively simple way to free up the
ACPI tables (which I am told may be sizable). With a bit of imagination
(and a fair amount of care), excluded memory regions can be accommodated
into such a system.

Clearly, it would be a Bad Idea(tm) to use a resource tree to specify good
(or bad) pages resulting from a bad line in a memory module.

What we can do is loop over the structure which is set up to hold the
base:mask data from the command line--for every page. Both David & I are
strongly opposed to doing this (looping over structure arrays for every
page), which was the first motivator to develop the memory page resource
tree. (It actually greatly simplifies a number of tasks.)

A really bright spark might notice that one might use the resource tree to
flag a region "striped", and for such a region, retrieve the base:mask pair
at issue & determine availability from there. This works great--so long as
you do not have two such areas overlapping (which you might get around by
looping the whole list)--and the entire region lies within what is otherwise
one region of usable memory.

The real fun starts when you have bad memory in the same region as the ACPI
tables. The ACPI table region has to be reclaimed by the ACPI driver, so
things have been cooking for quite a while. The data structure holding the
base:mask data then must be saved up until that point. (Presumably the ACPI
driver faults if it detected/was told that there was bad memory where it
needs to have data.)

And bad memory around the NVS data is just bad.


So yes, it can be done. I am not convinced, however, that it SHOULD be
done. If your memory goes bad, your whole system is jeopardized. Allowing
users to soldier on while their system is losing its mind does not seem to
me to be a very good thing.

Nathan




> -----Original Message-----
> From: vanrein@cs.utwente.nl [mailto:vanrein@cs.utwente.nl]
> Sent: Tuesday, March 21, 2000 3:58 AM
> To: Zook, Nathan
> Cc: vanrein@cs.utwente.nl; linux-kernel@vger.rutgers.edu
> Subject: Re: Where is memory handed out?
>
>
> Hi Nathan:
>
> > [...] if you were to specify, for instance, one bad byte
> > every 8k, you would get a series of single pages
> unavailable to handle mem
> > requests of larger amounts.
>
> I am not 100% certain of how VM-allocation works but...
>
> In mm/vmalloc.c, the nesting of routines to do virtual memory
> allocation is:
> vmalloc
> vmalloc_area_pages
> alloc_area_pmd
> alloc_area_pte
> __get_free_page
> The latter routine is defined in mm/page_alloc.c and
> allocates a single
> page. And for virtual memmory, that is the right thing to do.
> The kernel
> may need long stretches of pages in sequence, but user
> processes are quite
> happy to deal with loose pages concatenated any way.
>
> In a DIMM that I got working, there is an 8MB range in which
> error bytes
> are separated by 8kB and 24kB in turn. In the 8kB, there's
> one useful page
> (on i386), in the 24kB there are 5. Together, 6 pages out of 8.
> You would prefer to throw out 8MB whereas I only sacrifice 2MB. Your
> memory map (instead of the :X notation) may however make a difference.
> I am curious about your memory map syntax, and I wonder if it
> requires a
> parser (I use available routines for cmdline parsing).
>
>
> I do not intend to let this become a competition; I just want
> to learn of
> alternatives and perhaps teach others while at it.
>
>
> Cheers,
> -Rick.
>

-
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.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.023 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site