lkml.org 
[lkml]   [2004]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] per-user signal pending and message queue limits
On Tue, Apr 20, 2004 at 04:34:43PM -0700, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > > The major advantage of your work is that we can now remove those limits.
> > > You'll be needing a 2.4 backport ;)
> >
> > Yeap. :)
> >
> > And we also need to do the userspace part. ulimit is part of bash, so
> > probably all shell's should be awared of this? I never looked
> > how "ulimit" utility works.
>
> yup, the shells need to be changed, which is really awkward. I was wrong
> about how bash and zsh handle `ulimit 4 1024'.
>
> Really the shells _should_ permit ulimit-by-number for this very reason.
>
> Adding new ulimits is nice - it's a shame that the shells make it hard to
> use.

I'm thinking about how to do the mqueue "kernel allocated memory" accounting,
and I have a problem. A user can create an mqueue of given size via sys_mq_open()
using "msg_attr" structure (will be created in do_create). I can account for how much
memory has been allocated, but I can't at "deaccount" at kfree() time (this memory
is stored in inode->(mqueue_inode_info *)info->messages), because I dont know how big
it is (its user selectable via "msg_attr" structure).

What can be done about this?

Creating a data structure to account for "allocation->allocation size"
sounds overly complicated at first, but might be necessary if correct
accounting is necessary?

Gracias

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.053 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site