size limit for TMPFS

In current implementation of tmpfs, the size limit of a
tmpfs (which
is passed when mounting) only count the file size. The
memory used for
directories is not limit. This due to the fact that there is
not easy
and fast way to track a uma_zone's memory usage.

there are several approach:
1. hack vm to support a hook when uma_zone allocate a new
page. this
approach comes from Rohit Jalan. This also need some new API
in uma(9)
uma_set_allocate_hook
uma_set_deallocate_hook


2. Add a new API to uma(9) to report its memory usage. This
will
require traveling a link list inside uma_zone.
uma_get_paged

3. Guess a file number limit based on size if use doesn't
specific
explict, or get the number user sepcified. Use the number
limit
instead of size limit to limit the memory usage. This
doesn't need any
changes to uma. Also the implementation is clean.

I personally perfer way 3. Any suggestions?

-- 
-Howard
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

On 05/17/07 04:36, Howard Su wrote:
> In current implementation of tmpfs, the size limit of a
tmpfs (which
> is passed when mounting) only count the file size. The
memory used for
> directories is not limit. This due to the fact that
there is not easy
> and fast way to track a uma_zone's memory usage.
> 
> there are several approach:
> 1. hack vm to support a hook when uma_zone allocate a
new page. this
> approach comes from Rohit Jalan. This also need some
new API in uma(9)
> uma_set_allocate_hook
> uma_set_deallocate_hook
> 
> 
> 2. Add a new API to uma(9) to report its memory usage.
This will
> require traveling a link list inside uma_zone.
> uma_get_paged
> 
> 3. Guess a file number limit based on size if use
doesn't specific
> explict, or get the number user sepcified. Use the
number limit
> instead of size limit to limit the memory usage. This
doesn't need any
> changes to uma. Also the implementation is clean.
> 
> I personally perfer way 3. Any suggestions?
> 


Track the memory usage on your own?  As you allocate, keep a
counter and 
total up the usage outside of uma.  (3) sounds good, except
it may not 
be accurate, and that could lead to confusion for someone.


Eric

_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

On 5/17/07, Eric Anderson <andersonfreebsd.org> wrote:
>
> Track the memory usage on your own?  As you allocate,
keep a counter and
This is doable. The down site for this is we need another
mutex to
protect this resource usage. This mutex will result
performance issue.
because this mutex is per mount point. and when alloc/read a
node, a
directory.

> total up the usage outside of uma.  (3) sounds good,
except it may not
> be accurate, and that could lead to confusion for
someone.
Can we state, the tmpfs size only limit to the file size.
Meta data
will not be counted. Meta data limit will be adjusted by the
kernel
resource or explicitly specified by the user.

-- 
-Howard
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

On 05/18/07 01:28, Howard Su wrote:
> On 5/17/07, Eric Anderson <andersonfreebsd.org> wrote:
>> Track the memory usage on your own?  As you
allocate, keep a counter and
> This is doable. The down site for this is we need
another mutex to
> protect this resource usage. This mutex will result
performance issue.
> because this mutex is per mount point. and when
alloc/read a node, a
> directory.

 From a quick glance, you are storing your inode count in
the mount 
structure of the tmpfs.  So, anytime you do anything with
the fs, you 
have to lock the mount struct anyway, so there's no
additional mutex 
when updating the block count vs inode count, right?  Please
correct me 
if I'm wrong here, since I'm still learning much about
locking/vfs/etc.


>> total up the usage outside of uma.  (3) sounds
good, except it may not
>> be accurate, and that could lead to confusion for
someone.
> Can we state, the tmpfs size only limit to the file
size. Meta data
> will not be counted. Meta data limit will be adjusted
by the kernel
> resource or explicitly specified by the user.

Seems reasonable, and if it's documented in the man page, it
should 
reduce any confusion.


Eric

_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"

On 5/18/07, Eric Anderson <andersonfreebsd.org> wrote:
> On 05/18/07 01:28, Howard Su wrote:
>  From a quick glance, you are storing your inode count
in the mount
> structure of the tmpfs.  So, anytime you do anything
with the fs, you
> have to lock the mount struct anyway, so there's no
additional mutex
> when updating the block count vs inode count, right? 
Please correct me
> if I'm wrong here, since I'm still learning much about
locking/vfs/etc.
You are right in one persipective. the memory consumed by
inode can be
counted in this way.

However when we allocate the filename, dirent, you need
acquire the
mutex which is not needed currently.


-- 
-Howard
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"