)]}'
{
  "log": [
    {
      "commit": "60296d9e4be1cd9e096f7804ce6e839e0cbd97cf",
      "tree": "40372d93b1c99a0e488adedbbd8c843c26807058",
      "parents": [
        "e2adbcb480992de8a01acf9218e8bbd9b507fc6f"
      ],
      "author": {
        "name": "Santiago Leon",
        "email": "santil@us.ibm.com",
        "time": "Wed Oct 26 10:47:16 2005 -0600"
      },
      "committer": {
        "name": "Jeff Garzik",
        "email": "jgarzik@pobox.com",
        "time": "Fri Oct 28 16:07:30 2005 -0400"
      },
      "message": "[PATCH] ibmveth lockless TX\n\nThis patch adds the lockless TX feature to the ibmveth driver.  The\nhypervisor has its own locking so the only change that is necessary is\nto protect the statistics counters.\n\nSigned-off-by: Santiago Leon \u003csantil@us.ibm.com\u003e\nSigned-off-by: Jeff Garzik \u003cjgarzik@pobox.com\u003e\n"
    },
    {
      "commit": "e2adbcb480992de8a01acf9218e8bbd9b507fc6f",
      "tree": "92465e753d0221c0c54862994735a7fe078200fa",
      "parents": [
        "b6d35182fe62e57d368062adcc880ca35119d88e"
      ],
      "author": {
        "name": "Santiago Leon",
        "email": "santil@us.ibm.com",
        "time": "Wed Oct 26 10:47:08 2005 -0600"
      },
      "committer": {
        "name": "Jeff Garzik",
        "email": "jgarzik@pobox.com",
        "time": "Fri Oct 28 16:07:30 2005 -0400"
      },
      "message": "[PATCH] ibmveth fix buffer replenishing\n\nThis patch removes the allocation of RX skb\u0027s  buffers from a workqueue\nto be called directly at RX processing time.  This change was suggested\nby Dave Miller when the driver was starving the RX buffers and\ndeadlocking under heavy traffic:\n\n\u003e Allocating RX SKBs via tasklet is, IMHO, the worst way to\n\u003e do it.  It is no surprise that there are starvation cases.\n\u003e\n\u003e If tasklets or work queues get delayed in any way, you lose,\n\u003e and it\u0027s very easy for a card to catch up with the driver RX\u0027ing\n\u003e packets very fast, no matter how aggressive you make the\n\u003e replenishing.  By the time you detect that you need to be\n\u003e \"more aggressive\" it is already too late.\n\u003e The only pseudo-reliable way is to allocate at RX processing time.\n\u003e\n\nSigned-off-by: Santiago Leon \u003csantil@us.ibm.com\u003e\nSigned-off-by: Jeff Garzik \u003cjgarzik@pobox.com\u003e\n"
    },
    {
      "commit": "b6d35182fe62e57d368062adcc880ca35119d88e",
      "tree": "dd7767a40490d2d532cda4d35a18f8b8e614ab19",
      "parents": [
        "0abe791e94033b727f2b55670c2966f3d3d3cf70"
      ],
      "author": {
        "name": "Santiago Leon",
        "email": "santil@us.ibm.com",
        "time": "Wed Oct 26 10:47:01 2005 -0600"
      },
      "committer": {
        "name": "Jeff Garzik",
        "email": "jgarzik@pobox.com",
        "time": "Fri Oct 28 16:07:30 2005 -0400"
      },
      "message": "[PATCH] ibmveth fix buffer pool management\n\nThis patch changes the way the ibmveth driver handles the receive\nbuffers.  The old code mallocs and maps all the buffers in the pools\nregardless of MTU size and it also limits the number of buffer pools to\nthree. This patch makes the driver malloc and map the buffers necessary\nto support the current MTU. It also changes the hardcoded names of the\nbuffer pool number, size, and elements to arrays to make it easier to\nchange (with the hope of making them runtime parameters in the future).\n\nSigned-off-by: Santiago Leon \u003csantil@us.ibm.com\u003e\nSigned-off-by: Jeff Garzik \u003cjgarzik@pobox.com\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}