On 2014/7/24 1:14, Mikulas Patocka wrote:
On Wed, 23 Jul 2014, Alasdair G Kergon wrote:
On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
So, it means that you do not use device mapper at all. So, why are you
trying to change memory allocation in device mapper?
So the
On Wed, 23 Jul 2014, Alasdair G Kergon wrote:
> On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
> > So, it means that you do not use device mapper at all. So, why are you
> > trying to change memory allocation in device mapper?
>
> So the *test* they run is asking
On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
> So, it means that you do not use device mapper at all. So, why are you
> trying to change memory allocation in device mapper?
So the *test* they run is asking device-mapper to briefly reserve a 64KB
buffer when there is no data
On Tue, 22 Jul 2014, Zhang, Yanmin wrote:
> Sorry for replying you too late. I am very busy in some other critical issues.
>
> > The question is - does this particular kmalloc in device mapper cause out
> > of memory or killing of other tasks? It has flags __GFP_NORETRY,
>
> When memory is
On Wed, 23 Jul 2014, Zhang, Yanmin wrote:
> On 2014/7/22 9:23, Alasdair G Kergon wrote:
> > > > > On 2014/7/9 6:39, Mikulas Patocka wrote:
> > > > Which ioctl with more than 16kB
> > > > arguments do you use?
> > Unanswered. Let's ask the same question in a different way:
> >
> > Please
On Wed, 23 Jul 2014, Zhang, Yanmin wrote:
On 2014/7/22 9:23, Alasdair G Kergon wrote:
On 2014/7/9 6:39, Mikulas Patocka wrote:
Which ioctl with more than 16kB
arguments do you use?
Unanswered. Let's ask the same question in a different way:
Please supply the output of
On Tue, 22 Jul 2014, Zhang, Yanmin wrote:
Sorry for replying you too late. I am very busy in some other critical issues.
The question is - does this particular kmalloc in device mapper cause out
of memory or killing of other tasks? It has flags __GFP_NORETRY,
When memory is
On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
So, it means that you do not use device mapper at all. So, why are you
trying to change memory allocation in device mapper?
So the *test* they run is asking device-mapper to briefly reserve a 64KB
buffer when there is no data to
On Wed, 23 Jul 2014, Alasdair G Kergon wrote:
On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
So, it means that you do not use device mapper at all. So, why are you
trying to change memory allocation in device mapper?
So the *test* they run is asking device-mapper to
On 2014/7/24 1:14, Mikulas Patocka wrote:
On Wed, 23 Jul 2014, Alasdair G Kergon wrote:
On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
So, it means that you do not use device mapper at all. So, why are you
trying to change memory allocation in device mapper?
So the
On 2014/7/22 10:04, Alasdair G Kergon wrote:
On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote:
Unanswered. Let's ask the same question in a different way:
A quick search for 'vold' returns:
https://android.googlesource.com/platform/system/vold/
and the code there
On 2014/7/22 9:23, Alasdair G Kergon wrote:
On 2014/7/9 6:39, Mikulas Patocka wrote:
Which ioctl with more than 16kB
arguments do you use?
Unanswered. Let's ask the same question in a different way:
Please supply the output of these three commands on the real-world system on
which you
On 2014/7/22 9:23, Alasdair G Kergon wrote:
On 2014/7/9 6:39, Mikulas Patocka wrote:
Which ioctl with more than 16kB
arguments do you use?
Unanswered. Let's ask the same question in a different way:
Please supply the output of these three commands on the real-world system on
which you
On 2014/7/22 10:04, Alasdair G Kergon wrote:
On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote:
Unanswered. Let's ask the same question in a different way:
A quick search for 'vold' returns:
https://android.googlesource.com/platform/system/vold/
and the code there
On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote:
> Unanswered. Let's ask the same question in a different way:
A quick search for 'vold' returns:
https://android.googlesource.com/platform/system/vold/
and the code there requests a fixed 64K allocation to hold the names of
>>> On 2014/7/9 6:39, Mikulas Patocka wrote:
>> Which ioctl with more than 16kB
>> arguments do you use?
Unanswered. Let's ask the same question in a different way:
Please supply the output of these three commands on the real-world system on
which you believe that that particular allocation is
On 2014/7/9 22:53, Mikulas Patocka wrote:
On Wed, 9 Jul 2014, Zhang, Yanmin wrote:
On 2014/7/9 6:39, Mikulas Patocka wrote:
Hi
Mikulas,
Thanks for your kind comments.
I don't really know what is the purpose of this patch. In existing device
mapper code, if kmalloc fails, the allocation
On 2014/7/9 22:53, Mikulas Patocka wrote:
On Wed, 9 Jul 2014, Zhang, Yanmin wrote:
On 2014/7/9 6:39, Mikulas Patocka wrote:
Hi
Mikulas,
Thanks for your kind comments.
I don't really know what is the purpose of this patch. In existing device
mapper code, if kmalloc fails, the allocation
On 2014/7/9 6:39, Mikulas Patocka wrote:
Which ioctl with more than 16kB
arguments do you use?
Unanswered. Let's ask the same question in a different way:
Please supply the output of these three commands on the real-world system on
which you believe that that particular allocation is
On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote:
Unanswered. Let's ask the same question in a different way:
A quick search for 'vold' returns:
https://android.googlesource.com/platform/system/vold/
and the code there requests a fixed 64K allocation to hold the names of
On Wed, 9 Jul 2014, Zhang, Yanmin wrote:
> On 2014/7/9 6:39, Mikulas Patocka wrote:
>
> > Hi
>
> Mikulas,
>
> Thanks for your kind comments.
>
> > I don't really know what is the purpose of this patch. In existing device
> > mapper code, if kmalloc fails, the allocation is retried with
On Wed, 9 Jul 2014, Zhang, Yanmin wrote:
On 2014/7/9 6:39, Mikulas Patocka wrote:
Hi
Mikulas,
Thanks for your kind comments.
I don't really know what is the purpose of this patch. In existing device
mapper code, if kmalloc fails, the allocation is retried with __vmalloc.
So
于 2014年07月09日 10:01, Zhang, Yanmin 写道:
> On 2014/7/9 6:39, Mikulas Patocka wrote:
>
>> Hi
>
> Mikulas,
>
> Thanks for your kind comments.
>
>> I don't really know what is the purpose of this patch. In existing device
>> mapper code, if kmalloc fails, the allocation is retried with __vmalloc.
On 2014/7/9 6:39, Mikulas Patocka wrote:
Hi
Mikulas,
Thanks for your kind comments.
I don't really know what is the purpose of this patch. In existing device
mapper code, if kmalloc fails, the allocation is retried with __vmalloc.
So there is no need to avoid kmalloc aritifically.
kmalloc
Hi
I don't really know what is the purpose of this patch. In existing device
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.
Hi
I don't really know what is the purpose of this patch. In existing device
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.
On 2014/7/9 6:39, Mikulas Patocka wrote:
Hi
Mikulas,
Thanks for your kind comments.
I don't really know what is the purpose of this patch. In existing device
mapper code, if kmalloc fails, the allocation is retried with __vmalloc.
So there is no need to avoid kmalloc aritifically.
kmalloc
于 2014年07月09日 10:01, Zhang, Yanmin 写道:
On 2014/7/9 6:39, Mikulas Patocka wrote:
Hi
Mikulas,
Thanks for your kind comments.
I don't really know what is the purpose of this patch. In existing device
mapper code, if kmalloc fails, the allocation is retried with __vmalloc.
So there is
28 matches
Mail list logo
