Messages in this thread |  | | | Date | Sat, 3 Aug 2002 12:43:47 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: large page patch (fwd) (fwd) |
| |
On Sat, 3 Aug 2002, David Mosberger wrote: > > Your point about wanting databases have access to giant pages even > under memory pressure is a good one. I had not considered that > before. However, what we really are talking about then is a security > or resource policy as to who gets to allocate from a reserved and > pinned pool of giant physical pages.
Absolutely. We can't allow just anybody to allocate giant pages, since they are a scarce resource (set up at boot time in both Ingo's and Intels patches - with the potential to move things around later with additional interfaces).
> You don't need separate system > calls for that: with a transparent superpage framework and a > privileged & reserved giant-page pool, it's trivial to set up things > such that your favorite data base will always be able to get the giant > pages (and hence the giant TLB mappings) it wants. The only thing you > lose in the transparent case is control over _which_ pages need to use > the pinned giant pages. I can certainly imagine cases where this > would be an issue, but I kind of doubt it would be an issue for > databases.
That's _probably_ true. There aren't that many allocations that ask for megabytes of consecutive memory that wouldn't want to do it. However, there might certainly be non-critical maintenance programs (with the same privileges as the database program proper) that _do_ do large allocations, and that we don't want to give large pages to.
Guessing is always bad, especially since the application certainly does know what it wants.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |