On Wed, 9 Jul 2014, Zhang, Yanmin wrote:
On 2014/7/9 6:39, Mikulas Patocka wrote:
HiMikulas,
Thanks for your kind comments.
I don't really know what is the purpose of this patch. In existing deviceI agree with you. The patch's original description is not appropriate.
mapper code, if kmalloc fails, the allocation is retried with __vmalloc.
So there is no need to avoid kmalloc aritifically.
kmalloc doesn't cause memory fragmentation. If the memory is too
fragmented, kmalloc fails. If it isn't, it succeeds. But it doesn't cause
memory being fragmented.
Basically, memory fragmentation is not caused by this kmalloc.
The right description is: When memory is fragmented and most memory is used
up,
kmalloc a big memory might cause lots of OutOFMemory and system might kill
lots of processes. Then, system might hang.
The question is - does this particular kmalloc in device mapper cause out
of memory or killing of other tasks? It has flags __GFP_NORETRY,
__GFP_NOMEMALLOC, __GFP_NOWARN so it shouldn't cause any trouble. It
should just fail silently if memory is fragmented.
Do you have some stacktrace that identifies this kmalloc as a problem?
Do this test - prepare two kernels that are identical, except that one
kernel has that one-line change in dm-ioctl. Boot each kernel 10 times, do
exactly the same operation after boot. Does the kernel with the patch
always behave correctly and does the kernel without the patch always fail?
Report the result - how many failures did you get with or without that
one-line patch. Without such a test - I just don't believe that your patch
makes any difference.
Another question - your patch only makes change if some device mapper
ioctl has more than 16kB arugments. Which ioctl with more than 16kB
arguments do you use? Do you load such a big table to device mapper? How
often do you call that ioctl with such big arguments?