[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.

From: Valdis . Kletnieks
Subject: Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.
Date: Mon, 26 Nov 2012 21:22:16 -0500

On Mon, 26 Nov 2012 17:46:42 -0500, Paul Fox said:

> so, i've stumbled over rmmproc's limit in the past (and, like others,
> have quietly, manually, done it in chunks instead), but i don't think
> i've ever seen a similar limit with "rm".  and now i'm wondering, why
> not?  certainly this works just fine:
>     $ mkdir /tmp/many
>     $ cd /tmp/many
>     $ touch $(seq 1 100000)
>     $ ls | wc -l
>     100000

If you tried this on a Linux kernel that's newer than August 2007,
you probably will have to try harder to hit the argv[] limit.
The code in fs/exec.c now says:

                 * Limit to 1/4-th the stack size for the argv+env strings.
                 * This ensures that:
                 *  - the remaining binfmt code will not run out of stack space,
                 *  - the program will have a reasonable amount of stack left
                 *    to work from.
                rlim = current->signal->rlim;
                if (size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur) / 4) {
                        return NULL;

So if your default stack limit is 8M, you can exec() with up to 2M of
argv[] strings. If we're talking mh files, that means you can fit about
250K filenames into that 2M.

"250K filenames should be enough for anybody" -- Bill Gates, badly misquoted.

Attachment: pgp4n77BmaYUb.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]