On 8/18/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> Perhaps those application authors should provide a management interface
> to do so within the soft limit range at least. Its not clear to me that
> growing the fd array on a process is even safe. Some programs do size
> arrays at startup after query
Wieland Gmeiner <[EMAIL PROTECTED]> writes:
> (This resembles the behaviour of the ptrace system call.)
ptrace does not solve this problem because?
If you can do this now without a syscall why do you need
a syscall to optimize this code path?
Eric
-
To unsubscribe from this list: send the line
Wieland Gmeiner <[EMAIL PROTECTED]> wrote:
>
> +asmlinkage long sys_getprlimit(pid_t pid, unsigned int resource, struct
> rlimit __user *rlim)
> +{
> +struct rlimit value;
> +task_t *p;
> +int retval = -EINVAL;
> +
> +if (resource >= RLIM_NLIMITS)
> +
On Thu, 18 Aug 2005, Alan Cox wrote:
> > Also some documention for specific services show that there is a need to
> > adjust rlimits per process at runtime, e.g.:
> > http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.4
> > http://slacksite.com/apache/logging.html
> > http://staff.in2.hr/denis/or
On Fri, 2005-08-19 at 01:29 +0100, Alan Cox wrote:
> On Iau, 2005-08-18 at 19:16 -0400, Lee Revell wrote:
> > A search for a 200MB file tells you it's available on 2000 hosts, all of
> > whom are on dialup.
>
> What about the real world ?
>
OK that was a poorly contrived example. Anyway the s
On Iau, 2005-08-18 at 19:16 -0400, Lee Revell wrote:
> A search for a 200MB file tells you it's available on 2000 hosts, all of
> whom are on dialup.
What about the real world ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
On Fri, 2005-08-19 at 00:13 +0100, Alan Cox wrote:
> On Iau, 2005-08-18 at 14:17 -0400, Lee Revell wrote:
> > Maybe the distros need to just increase the default FD limit to 1024. I
> > hit this constantly with gtk-gnutella, if try to download a file that's
> > available on more than 1024 hosts it
On Iau, 2005-08-18 at 14:17 -0400, Lee Revell wrote:
> Maybe the distros need to just increase the default FD limit to 1024. I
> hit this constantly with gtk-gnutella, if try to download a file that's
> available on more than 1024 hosts it will open sockets until it hits
> that limit then bomb out
On Thu, 2005-08-18 at 18:19 +0200, Wieland Gmeiner wrote:
> As an example: It seems to be a common problem with numerous services
> to run out of available file descriptors. There are several
> workarounds to this problem, the most common seems to be increasing
> the systemwide max number of filede
> Also some documention for specific services show that there is a need to
> adjust rlimits per process at runtime, e.g.:
> http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.4
> http://slacksite.com/apache/logging.html
> http://staff.in2.hr/denis/oracle/10g1install_fedora3_en.html#n2
Perhaps tho
Wieland Gmeiner <[EMAIL PROTECTED]> writes:
> On Thu, 2005-08-18 at 04:05 +0200, Andi Kleen wrote:
>
> > Is there a realistic use case where this new system call is actually useful
> > and solves something that cannot be solved without it?
>
> As an example: It seems to be a common problem with
On Thu, 18 Aug 2005, Wieland Gmeiner wrote:
> On Thu, 2005-08-18 at 04:05 +0200, Andi Kleen wrote:
>
> > Is there a realistic use case where this new system call is actually useful
> > and solves something that cannot be solved without it?
>
> As an example: It seems to be a common problem with
On Thu, 2005-08-18 at 04:05 +0200, Andi Kleen wrote:
> Is there a realistic use case where this new system call is actually useful
> and solves something that cannot be solved without it?
As an example: It seems to be a common problem with numerous services to
run out of available file descriptor
Wieland Gmeiner <[EMAIL PROTECTED]> writes:
Is there a realistic use case where this new system call is actually useful
and solves something that cannot be solved without it?
If not I think it's better not to merge this to avoid unnecessary bloat.
-Andi
-
To unsubscribe from this list: send the
* Wieland Gmeiner ([EMAIL PROTECTED]) wrote:
> diff -uprN -X linux-2.6.13-rc6-vanilla/Documentation/dontdiff
> linux-2.6.13-rc6-vanilla/kernel/sys.c linux-2.6.13-rc6-getprlimit/kernel/sys.c
> --- linux-2.6.13-rc6-vanilla/kernel/sys.c 2005-08-09 16:03:21.0
> +0200
> +++ linux-2.6.13-rc
Hi!
I incorporated the changes suggested by Greg KH and Kyle Moffett and
isolated some duplicated code (between setrlimit/setprlimit resp.
getprlimit/setprlimit) into helper functions. This is the first of
two patches, it implements the getprlimit() call.
Rationale: Currently usage limits (rlimit
On Aug 16, 2005, at 13:34:34, Wieland Gmeiner wrote:
On Sat, 2005-08-13 at 15:11 -0700, Greg KH wrote:
On Fri, Aug 12, 2005 at 07:48:22PM +0200, Wieland Gmeiner wrote:
@@ -294,3 +294,4 @@ ENTRY(sys_call_table)
.long sys_inotify_init
.long sys_inotify_add_watch
.long sys_inotify_
On Tue, Aug 16, 2005 at 07:34:34PM +0200, Wieland Gmeiner wrote:
> On Sat, 2005-08-13 at 15:11 -0700, Greg KH wrote:
> > On Fri, Aug 12, 2005 at 07:48:22PM +0200, Wieland Gmeiner wrote:
> > > @@ -294,3 +294,4 @@ ENTRY(sys_call_table)
> > > .long sys_inotify_init
> > > .long sys_inotify_add_watc
On Sat, 2005-08-13 at 15:11 -0700, Greg KH wrote:
> On Fri, Aug 12, 2005 at 07:48:22PM +0200, Wieland Gmeiner wrote:
> > @@ -294,3 +294,4 @@ ENTRY(sys_call_table)
> > .long sys_inotify_init
> > .long sys_inotify_add_watch
> > .long sys_inotify_rm_watch
> > +.long sys_getprlimit
On Fri, Aug 12, 2005 at 07:48:22PM +0200, Wieland Gmeiner wrote:
> @@ -294,3 +294,4 @@ ENTRY(sys_call_table)
> .long sys_inotify_init
> .long sys_inotify_add_watch
> .long sys_inotify_rm_watch
> +.long sys_getprlimit
Please follow the proper kernel coding style when writi
Hi all!
I'm a participant in Googles Summer of Code Program, doing an entry
level kernel project suggested by Fedora Core, "Getting and Setting
Process Resource Limits out of Process Space".
Rationale: Currently resource usage limits (rlimits) can only be set
inside a process space, or inherited
21 matches
Mail list logo
