lkml.org 
[lkml]   [1999]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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