[Tux3] [PATCH 02/10] don't use preallocation if BUFFER_PARANOIA_DEBUG is defined

[OGAWA Hirofumi]

Daniel Phillips <phillips at phunq.net> writes:

>> That's great. Does it have (or plan) performance test too? I think, in
>> future performance regression also will become issue.
>
> Performance testing doesn't really make a lot of sense in user space,
> the fuse interface is a huge bottleneck, likewise the synchronous Posix
> IO calls.  We can start performance testing when we have a kernel port.

Yes.

> The kernel port can start as soon as we have a prototype of atom commit
> working in user space.
>
> Here is a first cut, partial list of tasks for the kernel port:
>
>   - Buffer operations need to be adapted to work with page cache and
>     bio instead of userspace synchronous Posix IO.

For now, I can't image what we want... BTW, do we support the blocksize
smaller than PAGE_CACHE_SIZE?

>   - Much glue to vfs *_operations methods.
>
>   - Mount options parsing, superblock load/save

Maybe, those are easy.

>   - Spinlocks for VFS ops

Um.. what does this mean?

>   - First cut btree, bitmap and atom table locking

Yes.

> This list is way incomplete, I just thought I'd start it now and flesh
> it out as we get closer.
>
> We will avoid the biggish job of converting any "non grata" C99 features
> such as inline declarations for now by just disabling the C99 warnings
> in kernel, and use defines/macros to make most of the user space code
> compile in kernel just as it is, for the time being.
>
> Spinlocks typically require that some high traffic code be refactored
> in unnatural ways.  We will do this for the kernel code and backport
> that code to userspace, either using empty macros in userspace or
> perhaps SysV semaphores for a more realistic simulation.

In future, how are we going to use the userland? I worry we are bothered
to sync userland <-> kernel...

> We will start with simple minded per-inode monolithic locks for btree
> access, allocation for now, then add high tech granular locks bit by
> bit.

Ok.

> In kernel, nearly everything is parallel and asynchronous, unlike the
> userspace code where the tux3 high level simulation is strictly single
> threaded and fuse linearizes everything by default.  We could start to
> work on the parallel aspects in userspace by going to pthreads and
> pthread mutexes under fuse, but it is not clear that that would
> actually save time versus just jumping straight into kernel with a
> little bit of sandbox work using user mode linux in smp mode.  If
> somebody else wants to take a run at adding pthreads to tux3fuse, they
> would be more than welcome, but I will shift my own effort into kernel
> pretty soon.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3