Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 2 Jul 1999 17:34:23 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: hashtables allocated with __get_free_pages() |
| |
On Fri, 2 Jul 1999, David S. Miller wrote:
>Andrea do you read my emails at all? On some systems the hash tables
Yes.
>will be larger that a few MB and GFP guarentees it will use the >smallest number of TLB entries.
I think TLB misses are not an issue (both the PTEs/virtual/physical memory would be the same with the only difference that I would allocate such memory without using GFP). I never proposed to alloc the hashtable with vmalloc.
I think I have seen a possible subtle problem with my approch on no-i386 arch though. If somebody (hardware vendor) would put an hole in the MM (note: mem_init is aware of the hole and so it would alloc in the MM-free-areas only the real-RAM pages) we could risk to use the hole as RAM with my approch. This can't happens using GFP since the pages are been alloced via mem_init that as just said would be aware of the holes.
The memory after memory_start is without holes on i386 so I think my approch would be fine at least there. And btw at least the profiler buffer _just_ suppose that there can't be holes after memory_start and so it may be _silenty_ buggy as well in such a weird MM-hardware envinrnemnt (so if you rise this problem as the reason for using GFP to alloc the buffer/page hash remeber we have to fix also the other things just present in main.c).
Comments?
Andrea
PS. I hope I am not missing something stupid causing you a waste of time...
- 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/
| ![\](/images/icornerr.gif) |