Help learning from my mistakes

Help learning from my mistakes

[Nicholas Krause]

Greetings All, 
I am wondering if there are any stupid mistakes in my attempts at kernel programming I am still making. 
Thanks, 
Nick 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Help learning from my mistakes

[Valdis.Kletnieks at vt.edu]

On Fri, 03 Apr 2015 17:23:04 -0400, Nicholas Krause said:
> Greetings All,
> I am wondering if there are any stupid mistakes in my attempts at kernel programming I am still making.

See the find|grep command I posted yesterday that you should have done
before posting.
-------------- 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/20150403/eae2980e/attachment.bin 

Help learning from my mistakes

[Nicholas Krause]

On April 3, 2015 8:13:35 PM EDT, Valdis.Kletnieks at vt.edu wrote:
>On Fri, 03 Apr 2015 17:23:04 -0400, Nicholas Krause said:
>> Greetings All,
>> I am wondering if there are any stupid mistakes in my attempts at
>kernel programming I am still making.
>
>See the find|grep command I posted yesterday that you should have done
>before posting.
After reading this it seems that the issue is my lack of effort not my abilities.
Nick 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Help learning from my mistakes

[Robert P. J. Day]

On Sat, 4 Apr 2015, Nicholas Krause wrote:

>
>
> On April 3, 2015 8:13:35 PM EDT, Valdis.Kletnieks at vt.edu wrote:
> >On Fri, 03 Apr 2015 17:23:04 -0400, Nicholas Krause said:
> >> Greetings All,
> >> I am wondering if there are any stupid mistakes in my attempts at
> >kernel programming I am still making.
> >
> >See the find|grep command I posted yesterday that you should have done
> >before posting.
> After reading this it seems that the issue is my lack of effort not my abilities.
> Nick

  can't it be both?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Help learning from my mistakes

[Nicholas Krause]

On April 4, 2015 3:32:06 PM EDT, "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>On Sat, 4 Apr 2015, Nicholas Krause wrote:
>
>>
>>
>> On April 3, 2015 8:13:35 PM EDT, Valdis.Kletnieks at vt.edu wrote:
>> >On Fri, 03 Apr 2015 17:23:04 -0400, Nicholas Krause said:
>> >> Greetings All,
>> >> I am wondering if there are any stupid mistakes in my attempts at
>> >kernel programming I am still making.
>> >
>> >See the find|grep command I posted yesterday that you should have
>done
>> >before posting.
>> After reading this it seems that the issue is my lack of effort not
>my abilities.
>> Nick
>
>  can't it be both?
>
>rday
It may be but I doubt it is due to my experience with high level programming. 
Nick 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Help learning from my mistakes

[Valdis.Kletnieks at vt.edu]

On Sat, 04 Apr 2015 15:28:23 -0400, Nicholas Krause said:

> After reading this it seems that the issue is my lack of effort not my abilities.

Being able to realize that the find|xargs grep solution was actually
less work, with quicker results, is *itself* an ability.
-------------- 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/20150404/81eb7173/attachment.bin 

Help learning from my mistakes

[Nicholas Krause]

On April 4, 2015 6:53:52 PM EDT, Valdis.Kletnieks at vt.edu wrote:
>On Sat, 04 Apr 2015 15:28:23 -0400, Nicholas Krause said:
>
>> After reading this it seems that the issue is my lack of effort not
>my abilities.
>
>Being able to realize that the find|xargs grep solution was actually
>less work, with quicker results, is *itself* an ability.
I agree my strength is not in finding the most effective way to debug or find an answer to a question.  I will slowly start working on it.  In the meantime I am having issues with the rc 6 candidate after enabling debugging for locks as my builds for kernels are now slower by up to 3 times,  I am assuming this is normal however please know if otherwise. 
Thanks, 
Nick 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Help learning from my mistakes

[Valdis.Kletnieks at vt.edu]

On Sat, 04 Apr 2015 19:00:42 -0400, Nicholas Krause said:
>  are now slower by up to 3 times,

So what debugging did you already do to try to narrow this down?

Did you even run 'top' or 'vmstat' or anything else like that?
Did you check to make sure you didn't replace a stripped down
custom config with a 'make allmodconfig'?  Did you compare the current
.config with the previous one to make sure enabling lock debugging
was the only change?  Did you reboot back into a known-good kernel
and test build a known-good kernel tree with a known-good .config (if
that was still slow, I'd start checking the system hardware to make sure
you haven't lost a 4G memory DIMM or other similar issue).

(Replying mostly for the archives, and the edification of others)
-------------- 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/20150405/252e3e3d/attachment.bin 

Help learning from my mistakes

[Kristof Provost]

On 2015-04-05 01:15:31 (-0400), Valdis.Kletnieks at vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Sat, 04 Apr 2015 19:00:42 -0400, Nicholas Krause said:
> >  are now slower by up to 3 times,
> 
> So what debugging did you already do to try to narrow this down?
>
While we're on the subject, let me indulge a pet peeve: How did you
measure this? Can you reproduce the measurement? Is the difference
statistically significant? What aspect of performance is worse? Task
switching time? IO throughput?

Benchmarking is *hard*, and 'up to 3 times' is not the result of a
careful, well thought out benchmark.

Regards,
Kristof

Help learning from my mistakes

[Nicholas Krause]

On April 5, 2015 8:29:47 AM EDT, Kristof Provost <kristof@sigsegv.be> wrote:
>On 2015-04-05 01:15:31 (-0400), Valdis.Kletnieks at vt.edu
><Valdis.Kletnieks@vt.edu> wrote:
>> On Sat, 04 Apr 2015 19:00:42 -0400, Nicholas Krause said:
>> >  are now slower by up to 3 times,
>> 
>> So what debugging did you already do to try to narrow this down?
>>
>While we're on the subject, let me indulge a pet peeve: How did you
>measure this? Can you reproduce the measurement? Is the difference
>statistically significant? What aspect of performance is worse? Task
>switching time? IO throughput?
>
>Benchmarking is *hard*, and 'up to 3 times' is not the result of a
>careful, well thought out benchmark.
>
>Regards,
>Kristof
I ran the make command on all of my CPU cores and timed  it.  Furthermore it seems to be slower up to 3 times then my distribution kernel based off 3.16.
Nick
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Help learning from my mistakes

[Kristof Provost]

On 2015-04-05 14:45:28 (-0400), Nicholas Krause <xerofoify@gmail.com> wrote:
> 
> 
> On April 5, 2015 8:29:47 AM EDT, Kristof Provost <kristof@sigsegv.be> wrote:
> >On 2015-04-05 01:15:31 (-0400), Valdis.Kletnieks at vt.edu
> ><Valdis.Kletnieks@vt.edu> wrote:
> >> On Sat, 04 Apr 2015 19:00:42 -0400, Nicholas Krause said:
> >> >  are now slower by up to 3 times,
> >> 
> >> So what debugging did you already do to try to narrow this down?
> >>
> >While we're on the subject, let me indulge a pet peeve: How did you
> >measure this? Can you reproduce the measurement? Is the difference
> >statistically significant? What aspect of performance is worse? Task
> >switching time? IO throughput?
> >
> >Benchmarking is *hard*, and 'up to 3 times' is not the result of a
> >careful, well thought out benchmark.
> >
> I ran the make command on all of my CPU cores and timed  it.  Furthermore it seems to be slower up to 3 times then my distribution kernel based off 3.16.

So, in other words, no, you've not done a careful benchmark at all.

What's the standard deviation on both measurements? How confident are
you (your answer should be a number) that there is a difference?
How have you accounted for VFS cache effects? Have you ensured that both
builds were from a completely clean tree? How have you ensured that no
other jobs interfered with the build (i.e. cron, user interaction, ...)?

Once you've established that there really is a difference you need to
start isolating contributing factors and figure out what's causing the
difference. Alternatively, you can start trying to figure out which part
of overall system performance has been degraded. That requires actually
understanding how the system works and using inspection tools (top,
iostat, perf, ...) to find out where the performance bottleneck is.

None of that is easy or quick. None of these questions can be answered
in one quick sentence. Certainly your overall answer should include more
information, and demonstrate more thought and effort, than 'I did a
build.'.

Regards,
Kristof

Help learning from my mistakes

[Nicholas Krause]

On April 5, 2015 3:05:18 PM EDT, Kristof Provost <kristof@sigsegv.be> wrote:
>On 2015-04-05 14:45:28 (-0400), Nicholas Krause <xerofoify@gmail.com>
>wrote:
>> 
>> 
>> On April 5, 2015 8:29:47 AM EDT, Kristof Provost <kristof@sigsegv.be>
>wrote:
>> >On 2015-04-05 01:15:31 (-0400), Valdis.Kletnieks at vt.edu
>> ><Valdis.Kletnieks@vt.edu> wrote:
>> >> On Sat, 04 Apr 2015 19:00:42 -0400, Nicholas Krause said:
>> >> >  are now slower by up to 3 times,
>> >> 
>> >> So what debugging did you already do to try to narrow this down?
>> >>
>> >While we're on the subject, let me indulge a pet peeve: How did you
>> >measure this? Can you reproduce the measurement? Is the difference
>> >statistically significant? What aspect of performance is worse? Task
>> >switching time? IO throughput?
>> >
>> >Benchmarking is *hard*, and 'up to 3 times' is not the result of a
>> >careful, well thought out benchmark.
>> >
>> I ran the make command on all of my CPU cores and timed  it. 
>Furthermore it seems to be slower up to 3 times then my distribution
>kernel based off 3.16.
>
>So, in other words, no, you've not done a careful benchmark at all.
>
>What's the standard deviation on both measurements? How confident are
>you (your answer should be a number) that there is a difference?
>How have you accounted for VFS cache effects? Have you ensured that
>both
>builds were from a completely clean tree? How have you ensured that no
>other jobs interfered with the build (i.e. cron, user interaction,
>...)?
>
>Once you've established that there really is a difference you need to
>start isolating contributing factors and figure out what's causing the
>difference. Alternatively, you can start trying to figure out which
>part
>of overall system performance has been degraded. That requires actually
>understanding how the system works and using inspection tools (top,
>iostat, perf, ...) to find out where the performance bottleneck is.
>
>None of that is easy or quick. None of these questions can be answered
>in one quick sentence. Certainly your overall answer should include
>more
>information, and demonstrate more thought and effort, than 'I did a
>build.'.
>
>Regards,
>Kristof
 The only difference I can tell is the kernel version.  I was wondering however if anyone who has more experience in the kernel can give me tips on how to address my benchmarking. 
Thanks, 
Nick

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Help learning from my mistakes

[Kristof Provost]

On 2015-04-05 15:15:12 (-0400), Nicholas Krause <xerofoify@gmail.com> wrote:
>  The only difference I can tell is the kernel version.  I was
>  wondering however if anyone who has more experience in the kernel can
>  give me tips on how to address my benchmarking. 
>
Nick, as you've been told again and again: *you* need to do the work. No
one is going to divide up the work in bite-sized chunks for you.
You have to do research, you have to think about what the logical next
step is, you have to actually *work* at this.

You keep asking what you can do to improve your reputation or get
unbanned from the kernel mailing list. It's actually simple enough: Do
the work, then show us that you've done it. Next time you ask a question
explain what you've tried and researched to answer your own question.
When people ask you questions, *answer* *all* of them.

You've essentially ignored all of the questions gave you (hint: those
are not just questions, they are parts of the work you have to
do).

Regards,
Kristof

Help learning from my mistakes

[Nicholas Krause]

On April 5, 2015 3:26:09 PM EDT, Kristof Provost <kristof@sigsegv.be> wrote:
>On 2015-04-05 15:15:12 (-0400), Nicholas Krause <xerofoify@gmail.com>
>wrote:
>>  The only difference I can tell is the kernel version.  I was
>>  wondering however if anyone who has more experience in the kernel
>can
>>  give me tips on how to address my benchmarking. 
>>
>Nick, as you've been told again and again: *you* need to do the work.
>No
>one is going to divide up the work in bite-sized chunks for you.
>You have to do research, you have to think about what the logical next
>step is, you have to actually *work* at this.
>
>You keep asking what you can do to improve your reputation or get
>unbanned from the kernel mailing list. It's actually simple enough: Do
>the work, then show us that you've done it. Next time you ask a
>question
>explain what you've tried and researched to answer your own question.
>When people ask you questions, *answer* *all* of them.
>
>You've essentially ignored all of the questions gave you (hint: those
>are not just questions, they are parts of the work you have to
>do).
>
>Regards,
>Kristofer. 
I am starting to understand.  I am busy today but willing to  start looking into this tomorrow. 
Nick

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.