diff for duplicates of <1494504995.3207.1.camel@primarydata.com> diff --git a/a/1.txt b/N1/1.txt index fc43a9f..31c8029 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,26 +1,46 @@ -T24gVGh1LCAyMDE3LTA1LTExIGF0IDA5OjU5ICswMjAwLCBNaWNoYWwgSG9ja28gd3JvdGU6DQo+ -IE9uIFRodSAxMS0wNS0xNyAxMDo1MzoyNywgTmlrb2xheSBCb3Jpc292IHdyb3RlOg0KPiA+IA0K -PiA+IA0KPiA+IE9uIDEwLjA1LjIwMTcgMTk6NDcsIFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4g -DQo+IFsuLi5dDQo+ID4gPiAtIENsZWFudXAgYW5kIHJlbW92YWwgb2Ygc29tZSBtZW1vcnkgZmFp -bHVyZSBwYXRocyBub3cgdGhhdA0KPiA+ID4gwqAgR0ZQX05PRlMgaXMgZ3VhcmFudGVlZCB0byBu -ZXZlciBmYWlsLg0KPiA+IA0KPiA+IFdoYXQgZ3VhcmFudGVlcyB0aGF0PyBTaW5jZSBpZiB0aGlz -IGlzIHRoZSBjYXNlIHRoZW4gdGhpcyBjYW4NCj4gPiByZXN1bHQgaW4NCj4gPiBhIGxvdCBvZiBv -cHBvcnR1bml0aWVzIGZvciBjbGVhbnVwIGFjcm9zcyB0aGUgd2hvbGUga2VybmVsIHRyZWUuDQo+ -ID4gQWZ0ZXINCj4gPiBkaXNjdXNzaW5nIHdpdGggbWhvY2tvIChjYydlZCkgaXQgc2VlbXMgdGhh -dCBpbiBwcmFjdGljZSBldmVyeXRoaW5nDQo+ID4gYmVsb3cgQ09TVExZX09SREVSIHdoaWNoIGFy -ZSBub3QgR0ZQX05PUkVUUlkgd2lsbCBuZXZlciBmYWlsLiBCdXQNCj4gPiB0aGlzDQo+ID4gc2Vt -YW50aWMgaXMgbm90IHRoZSBzYW1lIGFzIEdGUF9OT0ZBSUwuIEUuZy4gbm90aGluZyBndWFyYW50 -ZWVzDQo+ID4gdGhhdA0KPiA+IHRoaXMgd2lsbCBzdGF5IGxpa2UgdGhhdCBpbiB0aGUgZnV0dXJl -Pw0KPiANCj4gSW4gcHJhY3RpY2UgaXQgaXMgaGFyZCB0byBjaGFuZ2UgdGhlIHNlbWFudGljIG9m -IHNtYWxsIGFsbG9jYXRpb25zDQo+IG5ldmVyDQo+IGZhaWwgX3ByYWN0aWNhbGx5Xy4gQnV0IHRo -aXMgaXMgYWJzb2x1dGVseSBub3QgZ3VhcmFudGVlZCEgVGhleSBjYW4NCj4gZmFpbA0KPiBlLmcu -IHdoZW4gdGhlIGFsbG9jYXRpb24gY29udGV4dCBpcyB0aGUgb29tIHZpY3RpbS4gUmVtb3Zpbmcg -ZXJyb3INCj4gcGF0aHMNCj4gZm9yIGFsbG9jYXRpb24gZmFpbHVyZXMgaXMganVzdCB3cm9uZy4N -Cg0KT0ssIHRoaXMgbWFrZXMgbm8gZnVja2luZyBzZW5zZSBhdCBhbGwuDQoNCkVpdGhlciBhbGxv -Y2F0aW9ucyBjYW4gZmFpbCBvciB0aGV5IGNhbid0Lg0KMSkgSWYgdGhleSBjYW4ndCBmYWlsLCB0 -aGVuIHdlIGRvbid0IG5lZWQgdGhlIGNoZWNrcy4NCjIpIElmIHRoZXkgY2FuIGZhaWwsIHRoZW4g -d2UgZG8gbmVlZCB0aGVtLCBhbmQgdGhpcyBoYW5kIHdyaW5naW5nIGluDQp0aGUgTU0gY29tbXVu -aXR5IGFib3V0IEdGUF8qIHNlbWFudGljcyBhbmQgaG93IHdlIG5lZWQgdG8gcHJldmVudA0KZmFp -bHVyZSBpcyBmdWNraW5nIHBvaW50bGVzcy4NCg0KU28gd2hpY2ggaXMgaXQ/ICgxKSBvciAoMik/ -DQoNCg0KDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWlu -ZXIsIFByaW1hcnlEYXRhDQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= +On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote: +> On Thu 11-05-17 10:53:27, Nikolay Borisov wrote: +> > +> > +> > On 10.05.2017 19:47, Trond Myklebust wrote: +> +> [...] +> > > - Cleanup and removal of some memory failure paths now that +> > > GFP_NOFS is guaranteed to never fail. +> > +> > What guarantees that? Since if this is the case then this can +> > result in +> > a lot of opportunities for cleanup across the whole kernel tree. +> > After +> > discussing with mhocko (cc'ed) it seems that in practice everything +> > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But +> > this +> > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees +> > that +> > this will stay like that in the future? +> +> In practice it is hard to change the semantic of small allocations +> never +> fail _practically_. But this is absolutely not guaranteed! They can +> fail +> e.g. when the allocation context is the oom victim. Removing error +> paths +> for allocation failures is just wrong. + +OK, this makes no fucking sense at all. + +Either allocations can fail or they can't. +1) If they can't fail, then we don't need the checks. +2) If they can fail, then we do need them, and this hand wringing in +the MM community about GFP_* semantics and how we need to prevent +failure is fucking pointless. + +So which is it? (1) or (2)? + + + + +-- +Trond Myklebust +Linux NFS client maintainer, PrimaryData +trond.myklebust@primarydata.com diff --git a/a/content_digest b/N1/content_digest index 14a9277..b22fa95 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -11,31 +11,51 @@ " linux-nfs@vger.kernel.org <linux-nfs@vger.kernel.org>\0" "\00:1\0" "b\0" - "T24gVGh1LCAyMDE3LTA1LTExIGF0IDA5OjU5ICswMjAwLCBNaWNoYWwgSG9ja28gd3JvdGU6DQo+\n" - "IE9uIFRodSAxMS0wNS0xNyAxMDo1MzoyNywgTmlrb2xheSBCb3Jpc292IHdyb3RlOg0KPiA+IA0K\n" - "PiA+IA0KPiA+IE9uIDEwLjA1LjIwMTcgMTk6NDcsIFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4g\n" - "DQo+IFsuLi5dDQo+ID4gPiAtIENsZWFudXAgYW5kIHJlbW92YWwgb2Ygc29tZSBtZW1vcnkgZmFp\n" - "bHVyZSBwYXRocyBub3cgdGhhdA0KPiA+ID4gwqAgR0ZQX05PRlMgaXMgZ3VhcmFudGVlZCB0byBu\n" - "ZXZlciBmYWlsLg0KPiA+IA0KPiA+IFdoYXQgZ3VhcmFudGVlcyB0aGF0PyBTaW5jZSBpZiB0aGlz\n" - "IGlzIHRoZSBjYXNlIHRoZW4gdGhpcyBjYW4NCj4gPiByZXN1bHQgaW4NCj4gPiBhIGxvdCBvZiBv\n" - "cHBvcnR1bml0aWVzIGZvciBjbGVhbnVwIGFjcm9zcyB0aGUgd2hvbGUga2VybmVsIHRyZWUuDQo+\n" - "ID4gQWZ0ZXINCj4gPiBkaXNjdXNzaW5nIHdpdGggbWhvY2tvIChjYydlZCkgaXQgc2VlbXMgdGhh\n" - "dCBpbiBwcmFjdGljZSBldmVyeXRoaW5nDQo+ID4gYmVsb3cgQ09TVExZX09SREVSIHdoaWNoIGFy\n" - "ZSBub3QgR0ZQX05PUkVUUlkgd2lsbCBuZXZlciBmYWlsLiBCdXQNCj4gPiB0aGlzDQo+ID4gc2Vt\n" - "YW50aWMgaXMgbm90IHRoZSBzYW1lIGFzIEdGUF9OT0ZBSUwuIEUuZy4gbm90aGluZyBndWFyYW50\n" - "ZWVzDQo+ID4gdGhhdA0KPiA+IHRoaXMgd2lsbCBzdGF5IGxpa2UgdGhhdCBpbiB0aGUgZnV0dXJl\n" - "Pw0KPiANCj4gSW4gcHJhY3RpY2UgaXQgaXMgaGFyZCB0byBjaGFuZ2UgdGhlIHNlbWFudGljIG9m\n" - "IHNtYWxsIGFsbG9jYXRpb25zDQo+IG5ldmVyDQo+IGZhaWwgX3ByYWN0aWNhbGx5Xy4gQnV0IHRo\n" - "aXMgaXMgYWJzb2x1dGVseSBub3QgZ3VhcmFudGVlZCEgVGhleSBjYW4NCj4gZmFpbA0KPiBlLmcu\n" - "IHdoZW4gdGhlIGFsbG9jYXRpb24gY29udGV4dCBpcyB0aGUgb29tIHZpY3RpbS4gUmVtb3Zpbmcg\n" - "ZXJyb3INCj4gcGF0aHMNCj4gZm9yIGFsbG9jYXRpb24gZmFpbHVyZXMgaXMganVzdCB3cm9uZy4N\n" - "Cg0KT0ssIHRoaXMgbWFrZXMgbm8gZnVja2luZyBzZW5zZSBhdCBhbGwuDQoNCkVpdGhlciBhbGxv\n" - "Y2F0aW9ucyBjYW4gZmFpbCBvciB0aGV5IGNhbid0Lg0KMSkgSWYgdGhleSBjYW4ndCBmYWlsLCB0\n" - "aGVuIHdlIGRvbid0IG5lZWQgdGhlIGNoZWNrcy4NCjIpIElmIHRoZXkgY2FuIGZhaWwsIHRoZW4g\n" - "d2UgZG8gbmVlZCB0aGVtLCBhbmQgdGhpcyBoYW5kIHdyaW5naW5nIGluDQp0aGUgTU0gY29tbXVu\n" - "aXR5IGFib3V0IEdGUF8qIHNlbWFudGljcyBhbmQgaG93IHdlIG5lZWQgdG8gcHJldmVudA0KZmFp\n" - "bHVyZSBpcyBmdWNraW5nIHBvaW50bGVzcy4NCg0KU28gd2hpY2ggaXMgaXQ/ICgxKSBvciAoMik/\n" - "DQoNCg0KDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWlu\n" - ZXIsIFByaW1hcnlEYXRhDQp0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEuY29tDQo= + "On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote:\n" + "> On Thu 11-05-17 10:53:27, Nikolay Borisov wrote:\n" + "> > \n" + "> > \n" + "> > On 10.05.2017 19:47, Trond Myklebust wrote:\n" + "> \n" + "> [...]\n" + "> > > - Cleanup and removal of some memory failure paths now that\n" + "> > > \302\240 GFP_NOFS is guaranteed to never fail.\n" + "> > \n" + "> > What guarantees that? Since if this is the case then this can\n" + "> > result in\n" + "> > a lot of opportunities for cleanup across the whole kernel tree.\n" + "> > After\n" + "> > discussing with mhocko (cc'ed) it seems that in practice everything\n" + "> > below COSTLY_ORDER which are not GFP_NORETRY will never fail. But\n" + "> > this\n" + "> > semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees\n" + "> > that\n" + "> > this will stay like that in the future?\n" + "> \n" + "> In practice it is hard to change the semantic of small allocations\n" + "> never\n" + "> fail _practically_. But this is absolutely not guaranteed! They can\n" + "> fail\n" + "> e.g. when the allocation context is the oom victim. Removing error\n" + "> paths\n" + "> for allocation failures is just wrong.\n" + "\n" + "OK, this makes no fucking sense at all.\n" + "\n" + "Either allocations can fail or they can't.\n" + "1) If they can't fail, then we don't need the checks.\n" + "2) If they can fail, then we do need them, and this hand wringing in\n" + "the MM community about GFP_* semantics and how we need to prevent\n" + "failure is fucking pointless.\n" + "\n" + "So which is it? (1) or (2)?\n" + "\n" + "\n" + "\n" + "\n" + "-- \n" + "Trond Myklebust\n" + "Linux NFS client maintainer, PrimaryData\n" + trond.myklebust@primarydata.com -49ffd05397f589a9da4d8e91d235460f88bc3e16b14350cc2e53d219ac093e2a +a9ea59533c67194afeffe42d2a932cee398fe47180aa69232e6dce4f74045825
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.