>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/