All of lore.kernel.org
 help / color / mirror / Atom feed
* VFS/driver core overhead
@ 2015-04-07  3:12 nick
  2015-04-07 14:56 ` Valdis.Kletnieks at vt.edu
  0 siblings, 1 reply; 2+ messages in thread
From: nick @ 2015-04-07  3:12 UTC (permalink / raw)
  To: kernelnewbies

Greetings All,
After reading through the code for the usb and vfs core infrastructure, I was wondering if 
after reading it if I am correct in my notion of there being very little overhead or none
at all int these areas of the kernel. This is due to be noticing most drivers and file 
systems wrap around the core/vfs and therefore the overhead is very little and no need
to worry about it like the overhead of the kernel's process structures based off task_struct
.Honestly, I could benchmark this area of the kernel but it's hard to remove the file 
system/drivers interfering with my benchmarks due to me not knowing of any one way to do that.
If someone either points me to a benchmark for me to test this or answers it that would be
very helpful.
Thanks,
Nick

^ permalink raw reply	[flat|nested] 2+ messages in thread

* VFS/driver core overhead
  2015-04-07  3:12 VFS/driver core overhead nick
@ 2015-04-07 14:56 ` Valdis.Kletnieks at vt.edu
  0 siblings, 0 replies; 2+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2015-04-07 14:56 UTC (permalink / raw)
  To: kernelnewbies

On Mon, 06 Apr 2015 23:12:34 -0400, nick said:

(Replying mostly for the edification of those who can learn learn without
having to be spoon-fed)

> After reading through the code for the usb and vfs core infrastructure, I was wondering if
> after reading it if I am correct in my notion of there being very little overhead or none
> at all int these areas of the kernel. This is due to be noticing most drivers and file
> systems wrap around the core/vfs and therefore the overhead is very little and no need
> to worry about it like the overhead of the kernel's process structures based off task_struct

For bonus points, go learn the difference between latency and throughput, and
who cares about excessive overhead on each, and under what conditions, and
what solutions have already been tried to address the issue.

> .Honestly, I could benchmark this area of the kernel but it's hard to remove the file
> system/drivers interfering with my benchmarks due to me not knowing of any one way to do that.
> If someone either points me to a benchmark for me to test this or answers it that would be
> very helpful.

Step -1: Go back and re-read the recent postings about diagnosing slow kernel
builds, because you apparently didn't actually learn anything from them.

Step 0: Learn enough about proper benchmarking and the thing you're
benchmarking to be able to ask a meaningful, answerable question.

Step 1: Go find the proper tool for testing your question.

Step 2: Do the measurement needed to answer your question.
-------------- 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/20150407/ef0c4f8d/attachment.bin 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-04-07 14:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-07  3:12 VFS/driver core overhead nick
2015-04-07 14:56 ` Valdis.Kletnieks at vt.edu

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.