Questions about btrfs helper threads

[nick]

On 14-08-24 10:21 PM, nick wrote:
> 
> 
> On 14-08-24 11:22 AM, Valdis.Kletnieks at vt.edu wrote:
>> On Sun, 24 Aug 2014 01:49:07 -0400, nick said:
>>> After searching through parts of the btrfs code and docs. I am unable to find any information
>>> on the helper threads in btrfs and would like to known more about how their implemented and
>>> what are the reasons for helper threads in btrfs versus only 1 for journaling in ext3/ext3.
>>
>> Really?  *REALLY*?  You can't find anything?  What searching did you *DO*?
>>
>> [~] cd /usr/src/linux-next/
>> [/usr/src/linux-next] ls fs/btrfs
>> Kconfig         btrfs_inode.h      delayed-ref.h  extent-tree.o       hash.c        locking.o       props.h       root-tree.o     transaction.c  volumes.h
>> Makefile        built-in.o         delayed-ref.o  extent_io.c         hash.h        lzo.c           props.o       scrub.c         transaction.h  volumes.o
>> acl.c           check-integrity.c  dev-replace.c  extent_io.h         hash.o        lzo.o           qgroup.c      scrub.o         transaction.o  xattr.c
>> acl.o           check-integrity.h  dev-replace.h  extent_io.o         inode-item.c  math.h          qgroup.h      send.c          tree-defrag.c  xattr.h
>> async-thread.c  compression.c      dev-replace.o  extent_map.c        inode-item.o  modules.order   qgroup.o      send.h          tree-defrag.o  xattr.o
>> async-thread.h  compression.h      dir-item.c     extent_map.h        inode-map.c   ordered-data.c  raid56.c      send.o          tree-log.c     zlib.c
>> async-thread.o  compression.o      dir-item.o     extent_map.o        inode-map.h   ordered-data.h  raid56.h      struct-funcs.c  tree-log.h     zlib.o
>> backref.c       ctree.c            disk-io.c      file-item.c         inode-map.o   ordered-data.o  raid56.o      struct-funcs.o  tree-log.o
>> backref.h       ctree.h            disk-io.h      file-item.o         inode.c       orphan.c        rcu-string.h  super.c         ulist.c
>> backref.o       ctree.o            disk-io.o      file.c              inode.o       orphan.o        reada.c       super.o         ulist.h
>> btrfs.ko        delayed-inode.c    export.c       file.o              ioctl.c       print-tree.c    reada.o       sysfs.c         ulist.o
>> btrfs.mod.c     delayed-inode.h    export.h       free-space-cache.c  ioctl.o       print-tree.h    relocation.c  sysfs.h         uuid-tree.c
>> btrfs.mod.o     delayed-inode.o    export.o       free-space-cache.h  locking.c     print-tree.o    relocation.o  sysfs.o         uuid-tree.o
>> btrfs.o         delayed-ref.c      extent-tree.c  free-space-cache.o  locking.h     props.c         root-tree.c   tests           volumes.c
>>
>> Now take a look there in the left-hand column.  You *might* find
>> something useful there.
>>
>> As to the rest of your question, the ext filesystems have as a design goal
>> good performance on 1-2 core machines, while btrfs was designed to take
>> advantage of high-core-count machines. Hopefully you're a good enough
>> programmer that I don't have to explain further.
>>
>>
> Thanks for the answers and yes, I was searching in the wiki , not the tree sorry :( fucking brain fart). Thanks for information , in addition , when you mean multiple cores I am curious how many is btrfs scaling to in order to help me understand the locking requirements and more demanding locking I am finding in the btrfs code.
> Thanks Again for the Help,
> Nick   
> 
In addition , why not create a linked list for the compression in btrfs as we can then do the work using the already build in workqueues for btrfs and improve the scalability of the compression functions and workload it causes as compression
is very CPU intensive and we can easily take advance of workquenes in order to allow then to run when idle or rarely when CPU is under heavy load. 
Nick