path: root/arch/parisc/include/asm/pgalloc.h
AgeCommit message (Collapse)AuthorFilesLines
2016-06-24parisc: get rid of superfluous __GFP_REPEATMichal Hocko1-2/+1
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. pmd_alloc_one allocate PMD_ORDER which is 1. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: Signed-off-by: Michal Hocko <> Cc: "James E.J. Bottomley" <> Cc: Helge Deller <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2016-06-24tree wide: get rid of __GFP_REPEAT for order-0 allocations part IMichal Hocko1-2/+2
This is the third version of the patchset previously sent [1]. I have basically only rebased it on top of 4.7-rc1 tree and dropped "dm: get rid of superfluous gfp flags" which went through dm tree. I am sending it now because it is tree wide and chances for conflicts are reduced considerably when we want to target rc2. I plan to send the next step and rename the flag and move to a better semantic later during this release cycle so we will have a new semantic ready for 4.8 merge window hopefully. Motivation: While working on something unrelated I've checked the current usage of __GFP_REPEAT in the tree. It seems that a majority of the usage is and always has been bogus because __GFP_REPEAT has always been about costly high order allocations while we are using it for order-0 or very small orders very often. It seems that a big pile of them is just a copy&paste when a code has been adopted from one arch to another. I think it makes some sense to get rid of them because they are just making the semantic more unclear. Please note that GFP_REPEAT is documented as * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt * _might_ fail. This depends upon the particular VM implementation. while !costly requests have basically nofail semantic. So one could reasonably expect that order-0 request with __GFP_REPEAT will not loop for ever. This is not implemented right now though. I would like to move on with __GFP_REPEAT and define a better semantic for it. $ git grep __GFP_REPEAT origin/master | wc -l 111 $ git grep __GFP_REPEAT | wc -l 36 So we are down to the third after this patch series. The remaining places really seem to be relying on __GFP_REPEAT due to large allocation requests. This still needs some double checking which I will do later after all the simple ones are sorted out. I am touching a lot of arch specific code here and I hope I got it right but as a matter of fact I even didn't compile test for some archs as I do not have cross compiler for them. Patches should be quite trivial to review for stupid compile mistakes though. The tricky parts are usually hidden by macro definitions and thats where I would appreciate help from arch maintainers. [1] This patch (of 19): __GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. Yet we have the full kernel tree with its usage for apparently order-0 allocations. This is really confusing because __GFP_REPEAT is explicitly documented to allow allocation failures which is a weaker semantic than the current order-0 has (basically nofail). Let's simply drop __GFP_REPEAT from those places. This would allow to identify place which really need allocator to retry harder and formulate a more specific semantic for what the flag is supposed to do actually. Link: Signed-off-by: Michal Hocko <> Cc: "David S. Miller" <> Cc: "H. Peter Anvin" <> Cc: "James E.J. Bottomley" <> Cc: "Theodore Ts'o" <> Cc: Andy Lutomirski <> Cc: Benjamin Herrenschmidt <> Cc: Catalin Marinas <> Cc: Chen Liqin <> Cc: Chris Metcalf <> [for tile] Cc: Guan Xuetao <> Cc: Heiko Carstens <> Cc: Helge Deller <> Cc: Ingo Molnar <> Cc: Jan Kara <> Cc: John Crispin <> Cc: Lennox Wu <> Cc: Ley Foon Tan <> Cc: Martin Schwidefsky <> Cc: Matt Fleming <> Cc: Ralf Baechle <> Cc: Rich Felker <> Cc: Russell King <> Cc: Thomas Gleixner <> Cc: Vineet Gupta <> Cc: Will Deacon <> Cc: Yoshinori Sato <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2015-11-20parisc: Fix wrong comment regarding first pmd entry flagsHelge Deller1-1/+1
The first pmd entry is marked with PxD_FLAG_ATTACHED instead of _PAGE_GATEWAY. Signed-off-by: Helge Deller <>
2015-07-19parisc: mm: Fix a memory leak related to pmd not attached to the pgdChristophe Jaillet1-1/+2
Commit 0e0da48dee8d ("parisc: mm: don't count preallocated pmds") introduced a memory leak. After this commit, the 'return' statement in pmd_free is executed in all cases. Even for pmd that are not attached to the pgd. So 'free_pages' can never be called anymore, leading to a memory leak. Signed-off-by: Christophe JAILLET <> Acked-by: Kirill A. Shutemov <> Acked-by: Mikulas Patocka <> Acked-by: Helge Deller <> Cc: # v4.0+ Signed-off-by: Helge Deller <>
2015-04-21parisc: Replace PT_NLEVELS with CONFIG_PGTABLE_LEVELSGuenter Roeck1-3/+3
The following warning is seen when compiling parisc images ./arch/parisc/include/asm/pgalloc.h: In function 'pgd_alloc': ./arch/parisc/include/asm/pgalloc.h:29:5: warning: "PT_NLEVELS" is not defined Some definitions of PT_NLEVELS were missed with the conversion to CONFIG_PGTABLE_LEVELS. Fixes: f24ffde43237 ("parisc: expose number of page table levels on Kconfig level") Cc: Kirill A. Shutemov <> Signed-off-by: Guenter Roeck <> Acked-by: Kirill A. Shutemov <> Signed-off-by: Helge Deller <>
2015-04-14parisc: expose number of page table levels on Kconfig levelKirill A. Shutemov1-1/+1
We would want to use number of page table level to define mm_struct. Let's expose it as CONFIG_PGTABLE_LEVELS. Signed-off-by: Kirill A. Shutemov <> Cc: "James E.J. Bottomley" <> Cc: Helge Deller <> Tested-by: Guenter Roeck <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2015-03-23parisc: Fix pmd code to depend on PT_NLEVELS value, not on CONFIG_64BITHelge Deller1-5/+3
Make the code which sets up the pmd depend on PT_NLEVELS == 3, not on CONFIG_64BIT. The reason is, that a 64bit kernel with a page size greater than 4k doesn't need the pmd and thus has PT_NLEVELS = 2. Signed-off-by: Helge Deller <>
2015-03-23parisc: mm: don't count preallocated pmdsMikulas Patocka1-2/+7
The patch dc6c9a35b66b520cf67e05d8ca60ebecad3b0479 that counts pmds allocated for a process introduced a bug on 64-bit PA-RISC kernels. The PA-RISC architecture preallocates one pmd with each pgd. This preallocated pmd can never be freed - pmd_free does nothing when it is called with this pmd. When the kernel attempts to free this preallocated pmd, it decreases the count of allocated pmds. The result is that the counter underflows and this error is reported. This patch fixes the bug by artifically incrementing the counter in pmd_free when the kernel tries to free the preallocated pmd. Signed-off-by: Mikulas Patocka <> Acked-by: Kirill A. Shutemov <> Signed-off-by: Helge Deller <>
2013-11-15parisc: handle pgtable_page_ctor() failKirill A. Shutemov1-2/+6
Signed-off-by: Kirill A. Shutemov <> Cc: "James E.J. Bottomley" <> Cc: Helge Deller <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2008-10-10parisc: move include/asm-parisc to arch/parisc/include/asmKyle McMartin1-0/+149