/openbmc/linux/include/linux/mtd/ |
H A D | mtd.h | 33b53716 Fri Apr 08 10:51:32 CDT 2011 Grant Erickson <marathon96@gmail.com> mtd: create function to perform large allocations
Introduce a common function to handle large, contiguous kmalloc buffer allocations by exponentially backing off on the size of the requested kernel transfer buffer until it succeeds or until the requested transfer buffer size falls below the page size.
This helps ensure the operation can succeed under low-memory, highly- fragmented situations albeit somewhat more slowly.
Artem: so this patch solves the problem that the kernel tries to kmalloc too large buffers, which (a) may fail and does fail - people complain about this, and (b) slows down the system in case of high memory fragmentation, because the kernel starts dropping caches, writing back, swapping, etc. But we do not really have to allocate a lot of memory to do the I/O, we may do this even with as little as one min. I/O unit (NAND page) of RAM. So the idea of this patch is that if the user asks to read or write a lot, we try to kmalloc a lot, with GFP flags which make the kernel _not_ drop caches, etc. If we can allocate it - good, if not - we try to allocate twice as less, and so on, until we reach the min. I/O unit size, which is our last resort allocation and use the normal GFP_KERNEL flag.
Artem: re-write the allocation function so that it makes sure the allocated buffer is aligned to the min. I/O size of the flash.
Signed-off-by: Grant Erickson <marathon96@gmail.com> Tested-by: Ben Gardiner <bengardiner@nanometrics.ca> Tested-by: Stefano Babic <sbabic@denx.de> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 33b53716 Fri Apr 08 10:51:32 CDT 2011 Grant Erickson <marathon96@gmail.com> mtd: create function to perform large allocations Introduce a common function to handle large, contiguous kmalloc buffer allocations by exponentially backing off on the size of the requested kernel transfer buffer until it succeeds or until the requested transfer buffer size falls below the page size. This helps ensure the operation can succeed under low-memory, highly- fragmented situations albeit somewhat more slowly. Artem: so this patch solves the problem that the kernel tries to kmalloc too large buffers, which (a) may fail and does fail - people complain about this, and (b) slows down the system in case of high memory fragmentation, because the kernel starts dropping caches, writing back, swapping, etc. But we do not really have to allocate a lot of memory to do the I/O, we may do this even with as little as one min. I/O unit (NAND page) of RAM. So the idea of this patch is that if the user asks to read or write a lot, we try to kmalloc a lot, with GFP flags which make the kernel _not_ drop caches, etc. If we can allocate it - good, if not - we try to allocate twice as less, and so on, until we reach the min. I/O unit size, which is our last resort allocation and use the normal GFP_KERNEL flag. Artem: re-write the allocation function so that it makes sure the allocated buffer is aligned to the min. I/O size of the flash. Signed-off-by: Grant Erickson <marathon96@gmail.com> Tested-by: Ben Gardiner <bengardiner@nanometrics.ca> Tested-by: Stefano Babic <sbabic@denx.de> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|
/openbmc/linux/drivers/mtd/ |
H A D | mtdcore.c | 33b53716 Fri Apr 08 10:51:32 CDT 2011 Grant Erickson <marathon96@gmail.com> mtd: create function to perform large allocations
Introduce a common function to handle large, contiguous kmalloc buffer allocations by exponentially backing off on the size of the requested kernel transfer buffer until it succeeds or until the requested transfer buffer size falls below the page size.
This helps ensure the operation can succeed under low-memory, highly- fragmented situations albeit somewhat more slowly.
Artem: so this patch solves the problem that the kernel tries to kmalloc too large buffers, which (a) may fail and does fail - people complain about this, and (b) slows down the system in case of high memory fragmentation, because the kernel starts dropping caches, writing back, swapping, etc. But we do not really have to allocate a lot of memory to do the I/O, we may do this even with as little as one min. I/O unit (NAND page) of RAM. So the idea of this patch is that if the user asks to read or write a lot, we try to kmalloc a lot, with GFP flags which make the kernel _not_ drop caches, etc. If we can allocate it - good, if not - we try to allocate twice as less, and so on, until we reach the min. I/O unit size, which is our last resort allocation and use the normal GFP_KERNEL flag.
Artem: re-write the allocation function so that it makes sure the allocated buffer is aligned to the min. I/O size of the flash.
Signed-off-by: Grant Erickson <marathon96@gmail.com> Tested-by: Ben Gardiner <bengardiner@nanometrics.ca> Tested-by: Stefano Babic <sbabic@denx.de> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 33b53716 Fri Apr 08 10:51:32 CDT 2011 Grant Erickson <marathon96@gmail.com> mtd: create function to perform large allocations Introduce a common function to handle large, contiguous kmalloc buffer allocations by exponentially backing off on the size of the requested kernel transfer buffer until it succeeds or until the requested transfer buffer size falls below the page size. This helps ensure the operation can succeed under low-memory, highly- fragmented situations albeit somewhat more slowly. Artem: so this patch solves the problem that the kernel tries to kmalloc too large buffers, which (a) may fail and does fail - people complain about this, and (b) slows down the system in case of high memory fragmentation, because the kernel starts dropping caches, writing back, swapping, etc. But we do not really have to allocate a lot of memory to do the I/O, we may do this even with as little as one min. I/O unit (NAND page) of RAM. So the idea of this patch is that if the user asks to read or write a lot, we try to kmalloc a lot, with GFP flags which make the kernel _not_ drop caches, etc. If we can allocate it - good, if not - we try to allocate twice as less, and so on, until we reach the min. I/O unit size, which is our last resort allocation and use the normal GFP_KERNEL flag. Artem: re-write the allocation function so that it makes sure the allocated buffer is aligned to the min. I/O size of the flash. Signed-off-by: Grant Erickson <marathon96@gmail.com> Tested-by: Ben Gardiner <bengardiner@nanometrics.ca> Tested-by: Stefano Babic <sbabic@denx.de> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
|