Re: [PATCH 09/14] bdi: remove BDI_CAP_CGROUP_WRITEBACK

On 22/07/20 08:45, Johannes Thumshirn wrote: > On 22/07/2020 08:27, Christoph Hellwig wrote: >> it is know to support cgroup writeback, or the bdi comes from the block > knwon ~^ > Whoops - "known" > Apart from that, > Reviewed-by: Johannes Thumshirn > Cheers, Wol

Re: [LSF/MM TOPIC] (again) THP for file systems

On 14/02/19 01:59, Song Liu wrote: >> I believe the direction is clear. It needs people to do the work. >> > We're critically short of reviewers. I got precious little review of >> > the original XArray work, which made Andrew nervous and delayed its >> > integration. Now I'm getting little

Re: I/O hangs after resuming from suspend-to-ram

On 26/08/17 12:19, Martin Steigerwald wrote: > Also… when a hang happened the mouse pointer was frozen, Ctrl-Alt-F1 didn´t > work and so on… so it may easily be a completely different issue. > > I did not see much point in reporting it so far… as I have no idea on how to > reliably pin-point

Re: I/O hangs after resuming from suspend-to-ram

On 26/08/17 12:19, Martin Steigerwald wrote: > Also… when a hang happened the mouse pointer was frozen, Ctrl-Alt-F1 didn´t > work and so on… so it may easily be a completely different issue. > > I did not see much point in reporting it so far… as I have no idea on how to > reliably pin-point

Re: [PATCHv2] mdadm.c: fix compile error "switch condition has boolean value"

You can add my acked-by (never done it before, not sure how :-) Cheers, Wol On 30/03/17 17:58, Gioh Kim wrote: > Remove a boolean expression in switch condition > to prevent compile error of some compilers, > for example, gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2). > > Signed-off-by:

Re: [PATCHv2] mdadm.c: fix compile error "switch condition has boolean value"

You can add my acked-by (never done it before, not sure how :-) Cheers, Wol On 30/03/17 17:58, Gioh Kim wrote: > Remove a boolean expression in switch condition > to prevent compile error of some compilers, > for example, gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2). > > Signed-off-by:

Re: [PATCH] Revert "md: raid1: use bio helper in process_checks()"

On 28/03/17 16:02, Ming Lei wrote: >> What I meant is that a future change to the function might cause >> > another bug to go unnoticed later. > What is the future change? And what is another bug? Please don't suppose or > assume anything in future. What was that about some American General

Re: [PATCH] Revert "md: raid1: use bio helper in process_checks()"

On 28/03/17 16:02, Ming Lei wrote: >> What I meant is that a future change to the function might cause >> > another bug to go unnoticed later. > What is the future change? And what is another bug? Please don't suppose or > assume anything in future. What was that about some American General

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

On 29/07/16 01:50, Eric Wheeler wrote: > Hello all, > > With the many SSD caching layers being developed (bcache, dm-cache, > dm-writeboost, etc), how could we flag a bio from userspace to indicate > whether the bio is preferred to hit spinning disks instead of an SSD? > > Unnecessary

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

On 29/07/16 01:50, Eric Wheeler wrote: > Hello all, > > With the many SSD caching layers being developed (bcache, dm-cache, > dm-writeboost, etc), how could we flag a bio from userspace to indicate > whether the bio is preferred to hit spinning disks instead of an SSD? > > Unnecessary

Re: [PATCH] MAINTAINERS: correct entry for LVM

On 12/04/16 00:03, Joe Perches wrote: > I think that's not a particularly good definition. > MAINTAINERS describes the M: entry as: > > M: Mail patches to: FullName > > That _person_ is generally responsible for vetting patches > and bug fixing. Ahh ... you are ASS U ME

Re: [PATCH] MAINTAINERS: correct entry for LVM

On 12/04/16 00:03, Joe Perches wrote: > I think that's not a particularly good definition. > MAINTAINERS describes the M: entry as: > > M: Mail patches to: FullName > > That _person_ is generally responsible for vetting patches > and bug fixing. Ahh ... you are ASS U ME ing that it is a

Re: [PATCH] MAINTAINERS: correct entry for LVM

On 11/04/16 22:08, Joe Perches wrote: > I'm a native English speaker and I think that's a not > a good argument. > > Having the same entry for M: and L: where M: isn't an > actual person is not a great idea. > > The list is not a maintainer. > > Depends on your definition of maintainer ... To

Re: [PATCH] MAINTAINERS: correct entry for LVM

On 11/04/16 22:08, Joe Perches wrote: > I'm a native English speaker and I think that's a not > a good argument. > > Having the same entry for M: and L: where M: isn't an > actual person is not a great idea. > > The list is not a maintainer. > > Depends on your definition of maintainer ... To

Re: [PATCH] MAINTAINERS: correct entry for LVM

On 11/04/16 17:39, Sudip Mukherjee wrote: > On Monday 11 April 2016 09:53 PM, Alasdair G Kergon wrote: >> On Mon, Apr 11, 2016 at 09:45:01PM +0530, Sudip Mukherjee wrote: >>> L stands for "Mailing list that is relevant to this area", and this is a >>> mailing list. :) >> >> Your proposed patch

Re: [PATCH] MAINTAINERS: correct entry for LVM

On 11/04/16 17:39, Sudip Mukherjee wrote: > On Monday 11 April 2016 09:53 PM, Alasdair G Kergon wrote: >> On Mon, Apr 11, 2016 at 09:45:01PM +0530, Sudip Mukherjee wrote: >>> L stands for "Mailing list that is relevant to this area", and this is a >>> mailing list. :) >> >> Your proposed patch

Re: [RFC PATCH 0/7] evacuate struct page from the block layer

On 20/03/15 20:31, Matthew Wilcox wrote: > Ah! I've looked at that a couple of times as well. I asked our database > performance team what impact freeing up the memmap would have on their > performance. They told me that doubling the amount of memory generally > resulted in approximately a 40%

Re: [Linux-nvdimm] [RFC PATCH 0/7] evacuate struct page from the block layer

On 19/03/15 19:59, Andrew Morton wrote: > This is all contingent upon the prevalence of machines which have vast > amounts of nv memory and relatively small amounts of regular memory. > How confident are we that this really is the future? Somewhat off-topic, but it's also the past. I can't help

Re: [Linux-nvdimm] [RFC PATCH 0/7] evacuate struct page from the block layer

On 19/03/15 19:59, Andrew Morton wrote: This is all contingent upon the prevalence of machines which have vast amounts of nv memory and relatively small amounts of regular memory. How confident are we that this really is the future? Somewhat off-topic, but it's also the past. I can't help

Re: [RFC PATCH 0/7] evacuate struct page from the block layer

On 20/03/15 20:31, Matthew Wilcox wrote: Ah! I've looked at that a couple of times as well. I asked our database performance team what impact freeing up the memmap would have on their performance. They told me that doubling the amount of memory generally resulted in approximately a 40%