* Questions about btrfs helper threads
@ 2014-08-24 5:49 nick
2014-08-24 15:22 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 6+ messages in thread
From: nick @ 2014-08-24 5:49 UTC (permalink / raw)
To: kernelnewbies
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.
Nick
^ permalink raw reply [flat|nested] 6+ messages in thread
* Questions about btrfs helper threads
2014-08-24 5:49 Questions about btrfs helper threads nick
@ 2014-08-24 15:22 ` Valdis.Kletnieks at vt.edu
2014-08-25 2:21 ` nick
0 siblings, 1 reply; 6+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-08-24 15:22 UTC (permalink / raw)
To: kernelnewbies
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140824/6ceb1cc7/attachment.bin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Questions about btrfs helper threads
2014-08-24 15:22 ` Valdis.Kletnieks at vt.edu
@ 2014-08-25 2:21 ` nick
2014-08-25 3:31 ` nick
0 siblings, 1 reply; 6+ messages in thread
From: nick @ 2014-08-25 2:21 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Questions about btrfs helper threads
2014-08-25 2:21 ` nick
@ 2014-08-25 3:31 ` nick
2014-08-25 5:52 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 6+ messages in thread
From: nick @ 2014-08-25 3:31 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Questions about btrfs helper threads
2014-08-25 3:31 ` nick
@ 2014-08-25 5:52 ` Valdis.Kletnieks at vt.edu
2014-08-25 16:24 ` nick
0 siblings, 1 reply; 6+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-08-25 5:52 UTC (permalink / raw)
To: kernelnewbies
On Sun, 24 Aug 2014 23:31:38 -0400, nick said:
> 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.
Because fsync() exists.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140825/5b12a329/attachment.bin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Questions about btrfs helper threads
2014-08-25 5:52 ` Valdis.Kletnieks at vt.edu
@ 2014-08-25 16:24 ` nick
0 siblings, 0 replies; 6+ messages in thread
From: nick @ 2014-08-25 16:24 UTC (permalink / raw)
To: kernelnewbies
On 14-08-25 01:52 AM, Valdis.Kletnieks at vt.edu wrote:
> On Sun, 24 Aug 2014 23:31:38 -0400, nick said:
>> 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.
>
> Because fsync() exists.
>
>
About my other question how many cores is btrfs scaling to? I would like to known for reasons of understanding
the more strict locking I am finding in the btrfs code.
Nick
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-08-25 16:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-24 5:49 Questions about btrfs helper threads nick
2014-08-24 15:22 ` Valdis.Kletnieks at vt.edu
2014-08-25 2:21 ` nick
2014-08-25 3:31 ` nick
2014-08-25 5:52 ` Valdis.Kletnieks at vt.edu
2014-08-25 16:24 ` nick
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.