Tomas M:
> So if I understand all of this correctly, it would only make AUFS slower
> in remount time (adding a branch), but it would work the same speed
> after then. Am I correct? :)
Ah, I should write one more thing.
At adding a branch, the information for the root dir will be allocated
by k
Jan wrote:
> Nono. Reading and writing to said memory should have exactly the same
> speed. It is just in vmalloc and vfree that may take a bit more time
> while collecting enough single pages to satisfy the request.
Junjiro wrote:
> Aufs allocates such arrays at adding a branch, and refers them
Tomas M:
> What does aufs do more often? 'allocate' the memory, or 'use' the
> allocated memory?
Aufs allocates such arrays at adding a branch, and refers them every
time user does something. The essential information for inode and dentry
exist in the allocated arrays.
Junjiro Okajima
On Sep 14 2007 14:45, Tomas M wrote:
>> > Do you know are there (or are not there) any difference at performance
>> > between kmalloc and vmalloc?
>
> This guy here tested kmalloc versus vmalloc.
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0405.1/0559.html
>
> His result: for runtime perf
>> Do you know are there (or are not there) any difference at performance
>> between kmalloc and vmalloc?
This guy here tested kmalloc versus vmalloc.
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0405.1/0559.html
His result: for runtime performance vmalloc'ated memory doesn't appear
to per
Jan Engelhardt:
> There is probably a small penalty imposed since the virtual address area
I think so too.
That is why I postpone this issue until aufs users really need so much
branches. When the array is larger than the limit of kmalloc, aufs will
return an error.
Junjiro Okajima
---
On Sep 14 2007 21:25, [EMAIL PROTECTED] wrote:
>Jan Engelhardt:
>> So what is the problem of switching to vmalloc?
>
>Do you know are there (or are not there) any difference at performance
>between kmalloc and vmalloc?
There is probably a small penalty imposed since the virtual address area
that
Jan Engelhardt:
> So what is the problem of switching to vmalloc?
Do you know are there (or are not there) any difference at performance
between kmalloc and vmalloc?
Junjiro Okajima
-
This SF.net email is sponsored by: Micr
Tomas M:
> Can it cause any serious troubles for users, if they use more than eg.
> 256 branches? It seems it works OK for me. I didn't notice anything wrong.
Because kmalloc supports upto 128kb, it does no harm.
Junjiro Okajima
-
On Sep 14 2007 14:15, Tomas M wrote:
>[EMAIL PROTECTED] wrote:
>> Tomas M:
>>> You said that it's not prefered to allocate large memory blocks which
>>> require several pages. Does the paragraph above say that current aufs
>>> does exactly that? (allocate more). Or it does only for MAX_1023?
>>
[EMAIL PROTECTED] wrote:
> Tomas M:
>> You said that it's not prefered to allocate large memory blocks which
>> require several pages. Does the paragraph above say that current aufs
>> does exactly that? (allocate more). Or it does only for MAX_1023?
>
> What I wanted to say is, when I allocate
Tomas M:
> You said that it's not prefered to allocate large memory blocks which
> require several pages. Does the paragraph above say that current aufs
> does exactly that? (allocate more). Or it does only for MAX_1023?
What I wanted to say is, when I allocate a memory *by kmalloc*, I want
to
I'd like to return back to this paragraph
> Introducing CONFIG_AUFS_HINOTIFY and other features, the element of an
> array becomes a larger object than a pointer.
> So the array will be larger than a page at most.
You said that it's not prefered to allocate large memory blocks which
require seve
"Tomas M":
> In fact, I don't really need it that much. 1024 is enough for me today.
> But every limit is bad, in general... and moreover if the limit is only
> caused by the used function to allocate memory (kmalloc here), then there
> must be a way to rewrite it better :)
Then I postpone this i
> To allocate large memory which requires several pages, is not
> preferable. If kmalloc() in linux kernel supports several 128kb(for 32bit)
> or 256kb(for 64bit) allocations, you can enable MAX_32767 in safe.
> Actually, I don't know the exact limit of kmalloc. (I've heared it
> support upto 128kb
On Sep 13 2007 18:34, [EMAIL PROTECTED] wrote:
>Tomas M:
>> I noticed CONFIG_AUFS_BRANCH_MAX_32767 is still commented out in
>> local.mk so I didn't use it yet. Do you recommend it shouldn't be used
>> at all?
>
>It is up to linux memory allocation system.
>When you add a branch, aufs re-allocat
Tomas M:
> I noticed CONFIG_AUFS_BRANCH_MAX_32767 is still commented out in
> local.mk so I didn't use it yet. Do you recommend it shouldn't be used
> at all?
It is up to linux memory allocation system.
When you add a branch, aufs re-allocate some arrays for branch
management. Basically an elem
On Sep 13 2007 10:02, Tomas M wrote:
>
>I can see in aufs code that the only difference is that if MAX_127 is
>used, aufs_bindex_t is type 'signed char', while in other cases (for
>MAX_511, MAX_1023 and MAX_32767) aufs_bindex_t is type 'short'.
Think array. char foo[127] is smaller than int foo
Hello,
I am successfully using CONFIG_AUFS_BRANCH_MAX_1023=y for a long time,
and it seems the performance is not any different from the *_127 case.
Of course, if hundreds of branches are in aufs union, it's slower, but
that is completely understandable because it must lookup files in all
bran
Hi Tomas,
Tomas M:
> The final result is here:
Thank you for your explanation.
> (notice the absence of 'aufs' argument in front of /union) then it
> causes problem in LiveCD. The mount segfaults.
> - It doesn't matter if I have mount.aufs or not
> - it still doesn't matter if aufs is patched
> Please simply ignore this, I was talking about two different things at
> once. The problem can be reproduced only during LiveCD startup, using
> busybox command with 'aufs' parameter.
ergh. I was trying to say:
The problem can be reproduced only during LiveCD startup, using
busybox's mount co
> Which problem do you wrote as "unable to reproduce"?
Please simply ignore this, I was talking about two different things at
once. The problem can be reproduced only during LiveCD startup, using
busybox command with 'aufs' parameter.
> But aufs should work correctly which includes the expected
Tomas M:
> It was in Linux Live CD all the time, using 'mount' command from
> busybox. Now I tried it in a normal Linux (installed) and it doesn't
> segfault, remount simply exits with E2BIG (Argument list too long).
Thi is the effect of the patch I sent.
If you used the un-patched aufs, it wou
So now I tried something even more different :)
Before, I was calling unionctl to add branches one by one.
Now I decided to skip unionctl at all, and use
mount -n -o remount,add:1:/new/branch=ro aufs /union
directly for all branches. Note -n switch to bypass the mtab at all.
I removed mount.a
Yes it's still the same, starts with BUG: ... NULL pointer ...
even with the patched aufs loaded.
It was in Linux Live CD all the time, using 'mount' command from
busybox. Now I tried it in a normal Linux (installed) and it doesn't
segfault, remount simply exits with E2BIG (Argument list too lon
Tomas M:
> I tested the patch. No difference, remount,ro causes oops in
> kernel/exit.c:860
How about "BUG: ... NULL pointer ..."?
Your gif file showed me it before "BUG: at kernel/exit.c:860".
Junjiro Okajima
-
Using Tomc
I tested the patch. No difference, remount,ro causes oops in
kernel/exit.c:860
What should the patch do?
Thank you
Tomas M
> I think so.
> Will you try this patch?
>
> Junjiro Okajima
>
> Index: fs/aufs/opts.c
> ===
> RCS fil
Tomas M:
> and then I add branches one by one, by using
>
> mount -o remount,add:1:/mnt/images/image1 aufs /union
>
> for example. This works OK and branches are added to the union, but
> remounting the union ro causes the oops I sent you. Do you still agree
> it's a problem of the lenght
> Then, I will try sysfs instead of /proc.
> Give me some time.
>
> But I don't think it is good to implement
>> echo add:1:/mnt/path > /proc/fs/aufs/0/branches
>
> The (re)mount interface is better.
Thank you very much for your consideration!
I like the (re)mount very much, but will
Tomas M:
> Well, I believe that aufs should be made so it can handle branches
> differently, bypassing these limitations. Here is my suggestion. Would
> you please consider branch manipulation through /proc? The /proc/mounts
> would show only aufs is mounted somewhere and xino path and mount
>
> I think you can. But I have never tried actually.
> Also you need to change the type of aufs_bindex_t, which is also defined
> in aufs_type.h, such like this.
>
> typedef short aufs_bindex_t;
I believe the max amount of branches shouldn't be such small.
I suggest at least 256.
> But I am afrai
Tomas M:
> I believe it means that aufs can have only 127 branches now. Can I
> simply modify this value to 256 or more? Or is there any problem raising
> the max amount?
I think you can. But I have never tried actually.
Also you need to change the type of aufs_bindex_t, which is also defined
i
Hello,
I can see in aufs_type.h:
#define AUFS_BRANCH_MAX 127
I believe it means that aufs can have only 127 branches now. Can I
simply modify this value to 256 or more? Or is there any problem raising
the max amount?
Thank you very much
Tomas M
slax.org
--
33 matches
Mail list logo
