ependency is harder and this solves my problem.
> x86 allmodconfig builds, but there may be implicit include problems
> on other architectures.
For the block bits:
Acked-by: Jens Axboe
--
Jens Axboe
___
Linux-nvdimm mailing list -- linux-nvdi
f ->revalidate_disk entirely, but ther are a lot
> more patches needed for that.
Applied, thanks.
--
Jens Axboe
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
> path to issue to blk-mq, removing the need for the direct_make_request
> bypass.
Thanks, I'll try this again.
--
Jens Axboe
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
On 6/30/20 12:21 PM, Jens Axboe wrote:
> On 6/30/20 12:19 PM, Christoph Hellwig wrote:
>> On Tue, Jun 30, 2020 at 09:43:31AM -0600, Jens Axboe wrote:
>>> On 6/30/20 7:57 AM, Jens Axboe wrote:
>>>> On 6/29/20 1:39 PM, Christoph Hellwig wrote:
>>>>&g
On 6/30/20 12:19 PM, Christoph Hellwig wrote:
> On Tue, Jun 30, 2020 at 09:43:31AM -0600, Jens Axboe wrote:
>> On 6/30/20 7:57 AM, Jens Axboe wrote:
>>> On 6/29/20 1:39 PM, Christoph Hellwig wrote:
>>>> Hi Jens,
>>>>
>>>> this series moves t
On 6/30/20 7:57 AM, Jens Axboe wrote:
> On 6/29/20 1:39 PM, Christoph Hellwig wrote:
>> Hi Jens,
>>
>> this series moves the make_request_fn method into block_device_operations
>> with the much more descriptive ->submit_bio name. It then also gives
>> generic_
> path to issue to blk-mq, removing the need for the direct_make_request
> bypass.
Looks good to me, and it's a nice cleanup as well. Applied.
--
Jens Axboe
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe sen
e on down the IO was purely bio based, not buffer_heads.
Anyway, totally agree that it should just die, it's not that
interesting or useful anymore.
--
Jens Axboe
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an ema
us
> performanc improvements. Most of this comes from a series Konstantin
> sent a few weeks ago, rebased on changes that landed in your tree since
> and my change to always use the percpu version of the disk stats.
Applied, thanks.
--
Jens Axboe
with "PAGE_SECTORS_SHIFT" too
> and rename SECTOR_MASK to PAGE_SECTORS_MASK.
Applied, thanks.
--
Jens Axboe
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
ld seem saner to standardize rules around when
code is expected to hit the maintainers hands for kernel releases. Both
yours and Martins deals with that, there really shouldn't be the need
to have this specified in detail per sub-system.
--
Jens Axboe
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
utility [2] will ship a command to install the
> modprobe policy and include a man page that lists the potential
> regression risk to older FIO and other userspace tools that are hard
> coded to "/sys/class/dax".
>
> [1]: https://lwn.net/Articles/770128/
> [2]: https://git
On 10/10/18 1:59 PM, Bjorn Helgaas wrote:
> On Fri, Oct 05, 2018 at 07:16:04PM -0600, Jens Axboe wrote:
>> On 10/4/18 3:27 PM, Logan Gunthorpe wrote:
>>> QUEUE_FLAG_PCI_P2P is introduced meaning a driver's request queue
>>> supports targeting P2P memory. This w
re submitting P2P backed pages to submit_bio().
Nit pick, but the subject line still says that it checks support
for requests. This patch just adds the ability to flag support
in the queue.
--
Jens Axboe
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.
eue it's
> submitted to supports it, and enforce REQ_NOMERGE.
This changelog is no longer accurate.
--
Jens Axboe
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On 9/5/18 3:03 PM, Logan Gunthorpe wrote:
>
>
> On 05/09/18 02:36 PM, Jens Axboe wrote:
>> On 9/5/18 2:32 PM, Logan Gunthorpe wrote:
>>>
>>>
>>> On 05/09/18 02:19 PM, Jens Axboe wrote:
>>>> On 9/5/18 2:18 PM, Logan Gunthorpe wrote:
&g
On 9/5/18 2:32 PM, Logan Gunthorpe wrote:
>
>
> On 05/09/18 02:19 PM, Jens Axboe wrote:
>> On 9/5/18 2:18 PM, Logan Gunthorpe wrote:
>>>
>>>
>>> On 05/09/18 02:14 PM, Jens Axboe wrote:
>>>> But if the caller must absolutely know where the b
On 9/5/18 2:18 PM, Logan Gunthorpe wrote:
>
>
> On 05/09/18 02:14 PM, Jens Axboe wrote:
>> But if the caller must absolutely know where the bio will end up, then
>> it seems super redundant. So I'd vote for killing this check, it buys
>> us absolutely nothing
On 9/5/18 2:09 PM, Logan Gunthorpe wrote:
>
>
> On 05/09/18 02:11 PM, Christoph Hellwig wrote:
>> On Wed, Sep 05, 2018 at 01:54:31PM -0600, Jens Axboe wrote:
>>> On 9/5/18 1:56 PM, Christoph Hellwig wrote:
>>>> On Wed, Sep 05, 2018 at 01:45:04PM -0600, Jens
On 9/5/18 1:56 PM, Christoph Hellwig wrote:
> On Wed, Sep 05, 2018 at 01:45:04PM -0600, Jens Axboe wrote:
>> The point is that the caller doesn't necessarily know where the bio
>> will end up, hence the caller can't fully check if the whole stack
>> supports P2P.
&
On 9/5/18 1:33 PM, Logan Gunthorpe wrote:
>
>
> On 05/09/18 01:26 PM, Jens Axboe wrote:
>> On 9/3/18 4:26 PM, Logan Gunthorpe wrote:
>>> I personally agree with Christoph. But if there's consensus in the other
>>> direction or this is a real blocker moving
On 9/3/18 4:26 PM, Logan Gunthorpe wrote:
>
>
> On 01/09/18 02:28 AM, Christoph Hellwig wrote:
>> On Thu, Aug 30, 2018 at 01:11:18PM -0600, Jens Axboe wrote:
>>> I think this belongs in the caller - both the validity check, and
>>> passing in NOMERGE for this
On 8/30/18 1:17 PM, Logan Gunthorpe wrote:
>
>
> On 30/08/18 01:11 PM, Jens Axboe wrote:
>> On 8/30/18 12:53 PM, Logan Gunthorpe wrote:
>>> QUEUE_FLAG_PCI_P2P is introduced meaning a driver's request queue
>>> supports targeting P2P memory.
>>>
eue it's
> submitted to supports it, and enforce REQ_NOMERGE.
I think this belongs in the caller - both the validity check, and
passing in NOMERGE for this type of request. I don't want to impose
this overhead on everything, for a p
On 3/9/18 9:35 AM, Ross Zwisler wrote:
> On Fri, Mar 09, 2018 at 08:38:57AM -0700, Jens Axboe wrote:
>> On 3/9/18 8:38 AM, Jens Axboe wrote:
>>> On 3/8/18 5:20 PM, Ross Zwisler wrote:
>>>> This has gotten Reviewed-by tags from Christoph and Ming Lei.
>>>>
On 3/9/18 8:38 AM, Jens Axboe wrote:
> On 3/8/18 5:20 PM, Ross Zwisler wrote:
>> This has gotten Reviewed-by tags from Christoph and Ming Lei.
>>
>> Al, are you the right person to merge this? Or is the correct person Jens,
>> whom I accidentally didn't include
this got merged, and to see whether it was targeting
> v4.16 or v4.17.
I'm the right guy, but I don't see patches if I'm not cc'ed on them...
I have queued this up for 4.16, thanks.
--
Jens Axboe
___
Linux-nvdimm mailing list
move DAX support.
Reviewed-by: Jens Axboe
--
Jens Axboe
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On 08/15/2017 10:48 PM, Minchan Kim wrote:
> Hi Jens,
>
> On Mon, Aug 14, 2017 at 10:17:09AM -0600, Jens Axboe wrote:
>> On 08/14/2017 09:38 AM, Jens Axboe wrote:
>>> On 08/14/2017 09:31 AM, Minchan Kim wrote:
>>>>> Secondly, generally you d
On 08/14/2017 09:38 AM, Jens Axboe wrote:
> On 08/14/2017 09:31 AM, Minchan Kim wrote:
>>> Secondly, generally you don't have slow devices and fast devices
>>> intermingled when running workloads. That's the rare case.
>>
>> Not true. zRam is really pop
uct has a really poor slow nand compared to
> lz4/lzo [de]comression.
I guess that's true for some cases. But as I said earlier, the recycling
really doesn't care about this at all. They can happily coexist, and not
step on each others toes.
--
Jens Axboe
_
On 08/14/2017 09:06 AM, Minchan Kim wrote:
> On Mon, Aug 14, 2017 at 08:36:00AM -0600, Jens Axboe wrote:
>> On 08/14/2017 02:50 AM, Minchan Kim wrote:
>>> Hi Jens,
>>>
>>> On Fri, Aug 11, 2017 at 08:26:59AM -0600, Jens Axboe wrote:
>>>> On 08/11/2017
On 08/14/2017 02:50 AM, Minchan Kim wrote:
> Hi Jens,
>
> On Fri, Aug 11, 2017 at 08:26:59AM -0600, Jens Axboe wrote:
>> On 08/11/2017 04:46 AM, Christoph Hellwig wrote:
>>> On Wed, Aug 09, 2017 at 08:06:24PM -0700, Dan Williams wrote:
>>>> I like it, but do
two
ago, I'll see if I can find and resurrect it.
--
Jens Axboe
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
w_page |
> +
> | PMEM | 3.3 us| 3.27 us | 2.9 us |
> +
> | BTT | 3.7 us| 3.44 us | 3.4 us |
> +--++-+-+
>
> I've added another digit in precision in so
_flags manipulations introduced in commit
bbab37 ("block: Add support for DAX reads/writes to block devices").
Applied for 4.9, thanks.
--
Jens Axboe
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
[] device_add+0x125/0x610
[] device_create_groups_vargs+0xd8/0x100
[] device_create_vargs+0x1c/0x20
[] bdi_register+0x8c/0x180
[] bdi_register_dev+0x27/0x30
[] add_disk+0x175/0x4a0
Cc:
Reported-by: Yi Zhang
Tested-by: Yi Zhang
Signed-off-by: Dan Williams
Added for 4.8, t
cause it depended on CONFIG_BROKEN. This config option was
introduced in this commit:
commit 03cdadb04077 ("block: disable block device DAX by default")
This change reverts that commit, removing the dead config option.
This doesn't apply to master, nor for-linus
/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=51d1a5abcd0e88cb4528f35643245ea59cf234f1
Feel free to pick them up from patchwork or cherry-pick from
linux-dm.git
Added for 4.8, thanks!
--
Jens Axboe
___
Linux-nvdimm maili
.8/drivers and has
received a positive build success notification from the kbuild robot
across several configs.
[1]: "gendisk: Generate uevent after attribute available"
http://marc.info/?l=linux-virtualization&m=146725201522201&w=2
40 matches
Mail list logo
