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 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.
>>>
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 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/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 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 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: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 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
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
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.
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
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
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
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
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
> 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
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_
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 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
> 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
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
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
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
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.
>>>>
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
_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
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
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
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
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
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: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
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
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
.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
/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
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
[] 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
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
40 matches
Mail list logo
