Messages in this thread | | | From | nathan.zook@amd ... | Subject | RE: Where is memory handed out? | Date | Tue, 21 Mar 2000 14:16:59 -0600 |
| |
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/
| |