lkml.org 
[lkml]   [2016]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH v6 00/10] Intel Cache Allocation Technology
    Date
    > Gentlemen!
    >
    > After more than two years of tinkering and real engineering, we finaly have
    > skinned the CAT!

    Yeah! We made it!

    >
    > That was the most amazing review journey I ever made as a maintainer. Just
    > a few statistics:
    >
    > Design variants: 6
    >
    > 6 different approaches for a user space interface. 3 of them have been
    > actually implemented.
    >
    > Unfortunately the real interface discussion happened way after the first
    > rounds of patches had been sent and reviewed. See below.
    >
    > Patchsets: 21
    >
    > 21 patch sets were posted. These can be split into two generations.
    >
    > Gen1 16 Oct 2014 - Dec 2015
    >
    > Gen2 5 Jul 2016 - Oct 2016
    >
    > LKML-Mails: 1216

    Wow! You have such detailed statistics data!

    >
    > That's the number of mails related to this project sent to LKML,
    > according to my archive. About 1/3 of those mails are the postings of
    > the patchsets alone.
    >
    > I cannot tell how many offlist mails have been sent around in total on
    > this matter, but at least in my personal mail are close to hundred.
    >
    > Beers: Uncountable
    >
    > This applies to both the number of beers consumed and the number of
    > beers
    > owed.
    >
    > I'm pretty happy with the final outcome of these patches and I want to say
    > thanks to everyone!
    >
    > I know that I've been a pain in the neck for some of you due to my pedantery
    > about the details, but getting this wrong would have been a major disaster. If
    > I offended someone personally in course of the sometimes heated
    > discussions, then I offer my excuses.
    >
    > Some lessons can be learned from this endeavour:
    >
    > 1) Chip vendors should give access to the full documentation early
    >
    > 2) Reviewers should never trust patch submitters, that they have read
    > the documentation correctly and came to the right conclusions how to
    > handle such a facility.
    >
    > 3) User space interface discussions should be done upfront with a full
    > explanation of the inner workings of such a facility and full
    > documentation available.
    >
    > Anything else is just the usual churn of patch submissions, which are handled
    > by the submitters with different effectiveness levels.
    >
    > That said, all which needs to be done now is proper testing and a massive
    > exposure of the user space interface to fuzzers. I've implemented my share
    > of string parsers in the past and as careful as I was, there was always a hole in
    > them.

    We have a few internal test cases and we are enhancing them and doing more
    tests from our side.

    >
    > If any of the involved folks are at KS/LPC then I suggest we get together at a
    > bar during the week and drown the skinned CAT with the appropriate
    > beverages. The first round of drinks is my shout.

    I won't be in KS/LPC, unfortunately. But I really wish we can meet face to face
    in the near future.

    Is there any plan for you to travel to any Intel site recently? It would be great to
    have a celebration beer with you and discuss what we are going to do next:)

    Thanks.

    -Fenghua

    \
     
     \ /
      Last update: 2016-10-31 04:06    [W:3.741 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site