Received-SPF: pass (google.com: domain of linux-kernel+bounces-63072-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <1b16adba-7004-44e7-83e6-12d6c0a993aa@oracle.com>
Date: Tue, 13 Feb 2024 08:05:06 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 02/15] block: Limit atomic writes according to bio and
 queue limits
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>, axboe@kernel.dk,
        kbusch@kernel.org, hch@lst.de, sagi@grimberg.me, jejb@linux.ibm.com,
        martin.petersen@oracle.com, djwong@kernel.org, viro@zeniv.linux.org.uk,
        brauner@kernel.org, dchinner@redhat.com, jack@suse.cz
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-nvme@lists.infradead.org, linux-xfs@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, tytso@mit.edu, jbongio@google.com,
        linux-scsi@vger.kernel.org, ming.lei@redhat.com, ojaswin@linux.ibm.com,
        bvanassche@acm.org
References: <87h6idugnd.fsf@doe.com>
Content-Language: en-US
From: John Garry <john.g.garry@oracle.com>
Organization: Oracle Corporation
In-Reply-To: <87h6idugnd.fsf@doe.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?L05qZzJOc3VmcklqZ3RmUnRtSWN5Y1A1YVlJQU1xNTNYZTZUY0YrcXpiV21L?=
 =?utf-8?B?Qno3OFlqalFHWTlEU2s2Q1BuRnU3K25aYkJ6RVcwR1FqWXY5YW5wQkRxdzdW?=
 =?utf-8?B?bXlTTDk1QXh5ZjZ2Wnk2elZYblZHOFRpK01ncXRPMnNQdzBKNXVVNXgxL05q?=
 =?utf-8?B?eFFCMnhVVG9GUXJrK2NFUGRGK3NRSUpxZ3VpNDVxWTVWdXUxV1h5ZFBRWkdh?=
 =?utf-8?B?c2ZGNTFXU0lXTGFiMDFrQmdRTU5ScDRLV0Q2VHVlZXp0UHlGK0o2OEZJMVh1?=
 =?utf-8?B?Yk1KYjJ3ZDZ2SVdHaE1MelNIQUQxVFBoZmpsWXJKR1pPN1dhdGwzYlA2SVhm?=
 =?utf-8?B?b3ErQnNrY2J1NzlpSkZBWXRZRlVSZHl0NGpQb2FSdlVlT0d6cFJNc3V5SkZk?=
 =?utf-8?B?U003U1MvWXV6TDdVZU1nM0MyaGZxOHh2YzN5RW5tMEcvaUFhenhHRGd5aTVG?=
 =?utf-8?B?dXE0MXlENXc4bTZVNUxpQnlRcFk2Q1FlUk5ibW5sM3Y0ZmJFSVV4NXFBVGpi?=
 =?utf-8?B?Zk85VmxMRlZQclBQbWtiWjFyT0hRZHdKRFphWFNBU09kNGhYSG1jMHNiUEtv?=
 =?utf-8?B?UGdJZ3g4UjZlQ3hWVDd5bFVJdHRXRlBWc3RCVzBDbWhPdzNxMUU5MTJIVjJC?=
 =?utf-8?B?cFlYTWVQYWZVcG5kNThVTGxHZzNkMGhXbGRNem9iZ3FOZStuR0g4REdWL24w?=
 =?utf-8?B?RnJCNzZkcmxkYTNsWG5NNlQrd3RSeFY3TUxUc0MwSERqdWtKOFhXaytkOGtP?=
 =?utf-8?B?emxQRFJFT3MxV0NNTnNmVHJ0MkgwQUZhMTFoZEM3aUVsSllmRzF0d1ZtbHQy?=
 =?utf-8?B?Q3lyM2FOZmhydWNJZEljb0lRbkt2M1luOUpKd1JEMXpVUytOSHZjS3NRQ0xC?=
 =?utf-8?B?aktMMHhmY1VEa0gzdjJUcU1YdHJ6SnpFQzZvWFNYUlFJeVBFNGtpcng0cytz?=
 =?utf-8?B?cytkQUFwYXhhNlhCOTkySWtoYTJ0VWNDOVRvRUlsVjAvUks1MWZvZ2cxUE5Z?=
 =?utf-8?B?Y0N3b1phcU90ajJIcGpqRjNhTWFDc051ZU1HK1ZUdVJPQWljTEFuUGFlZldi?=
 =?utf-8?B?eW1SelZ4aGJwbVpFck02dlpYcGdLNGdvSzBWdjNYbitqSkRLUjI1SEE3RkdL?=
 =?utf-8?B?Zm90MVdrN2V1K0ZoTUJLY0loOTVJSG43a3dsYTYrZDNYS2hLK2JSZDA3c3l5?=
 =?utf-8?B?dnpMWFVYbkF2eXdIR3UvU2tvYlZ3bmhCd0U0Ymh6RlUwMG5EbjZWM3pqcm9D?=
 =?utf-8?B?MnhKallML1dzeno3QjEvc0doajVKRTRWYnpkeFR0RFJTbWdWM3lvVGhTWEtE?=
 =?utf-8?B?U01UQU9jUjZ3UXFZMDZlT3VZL3dCc2RpRkI4ZTVUdURvb1YrSnplTjFmSFZ1?=
 =?utf-8?B?K2dUa0w0eDJCaU1oMmNILzZya1JoZG04L3NGd2Fhb0JCaXk2UER4RS9MUzlp?=
 =?utf-8?B?VHhyaVdscUE2VlFVbmZaalJGSmIybEphWHBjVjNKYXkwSURBQ3F3ZzFsQXoz?=
 =?utf-8?B?WjZDdHZUTERFa3VCUFMrZ0t3MXplZGxUZjd1aThqNzhSRnYxME40TU1QOW05?=
 =?utf-8?B?cEdJZ3JXdXZZeTVBclNhNk9DUFU0akQzNVNUUnVZYUlLbVowY3NZS05vQTQ1?=
 =?utf-8?B?U1V4ZzlVZFo2YzBIZG8ycHpZMVYrWlc3YmNqcnY0RWJsUUViZHBHMkQwYWtX?=
 =?utf-8?B?R3hJTm1RcTNsWW1IS1NpMm9oSFNRRzVMU2dIV2t3R0JjS3lKeC9FMnRMdC9l?=
 =?utf-8?B?eWxPWTB1R1BMSHpNVE9Gd0NXaFV2WDJJdm44NUN6NlFxNGdpcWxiRlQwR1Ar?=
 =?utf-8?B?azl2OG5JdmJyRGU1L0ZTSlFDT0tYZFZxMFF4eUo4Y0h5Z1dFazFMRkV6eVIw?=
 =?utf-8?B?WUp5OUthRG1WU2x0ZEF1RzF3SUZxOGZWcjhIRElCdmJUaWtiTkFKVzJGNGg4?=
 =?utf-8?B?Yjg2NUVDRGtPYlR6TWxEWVpKdms4TkJIZmJudVh5SXBsakx1OVFTNDVEME1t?=
 =?utf-8?B?RkIrdmkxT1JZekVNMjNXK241WERmR1loNUEydzV4UDQrRHBYVHRUa0ZhMFI5?=
 =?utf-8?B?UnlWYXZlNHBITmdnek9mWjAyK2xoRmVZRVVIL2NTTFAwV3d2ajhMVVEwYmc4?=
 =?utf-8?Q?YwgvuLOLQ6iRWIvolrQQOILJB?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	dLEab8KzH/LtwRgE5jvkuyIj8IraEhMiucSiohHaRK+NzICclukz3VeRPSI5A6XmXgxZ0y57EpVEZPk8zlCmtdjSp2mHvNqI9POhQ3fU2noOMrdNRPXL7H1hzhNZ8rhw0uBU8u2oAq8nS7Pf4nPzPT1qkizPqrVL4d24JpsZVHGIEEUTiGCgv35cyDCT9S+wbz8sDs2yx7f2zKwgLV5Z6z99j6PLOP3xCRDvoGKd7h7zQvr/Xqg599iXW1h5+02VresRawRFdUZB78Mbp+LIu+88jNpcyNOeDYeq7N3IGKknx+tqT92ptShRMt0jOD7uFecUkMRQaIWmU0ett4Y8v610WDMV+28kfZy0GOYqkqwugN7q6fn0WuFv/gjpL+n2x3ROpfqk4dkzY8FVXomneggyZCcVsEL6AkcJq9pyaC1/U2rBgxL+TNeBaeQ+cZd0WDN1Kf+/mwJAO8DGl1KkQ+xmEJuJ/NNrgoUpdw0oy3GBW6oWwe3KS0wa7vTfeEeGbxHYrMzGKS81CmbdGHIqE1u0MhfPgQ5aYncXXs4BwkdVPOtEg2uWerabTznIdST9v7asymhTtJiLcBDlZyGdLhMxLsG8zWvKZCWNaMo8nWU=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a625e55-e96a-4d75-777c-08dc2c6a808e
X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB4313.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2024 08:05:11.7377
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: BfG23o/qDzoKHhe3P19MW8tpf0fg1EOnpLrDogM5j5vY9rP/CvT71ivtmq2OSqf0NSy6UiDWv5rxaTDcIvNl9g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB6220
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-02-13_04,2024-02-12_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0
 mlxlogscore=999 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2402130062
X-Proofpoint-ORIG-GUID: kkVWY63roWKH5qTKHjp5TxySthcYRWl1
X-Proofpoint-GUID: kkVWY63roWKH5qTKHjp5TxySthcYRWl1

On 13/02/2024 04:33, Ritesh Harjani (IBM) wrote:
>> diff --git a/block/blk-settings.c b/block/blk-settings.c
>> index 11c0361c2313..176f26374abc 100644
>> --- a/block/blk-settings.c
>> +++ b/block/blk-settings.c
>> @@ -108,18 +108,42 @@ void blk_queue_bounce_limit(struct request_queue *q, enum blk_bounce bounce)
>>   }
>>   EXPORT_SYMBOL(blk_queue_bounce_limit);
>>   
>> +
>> +/*
>> + * Returns max guaranteed sectors which we can fit in a bio. For convenience of
>> + * users, rounddown_pow_of_two() the return value.
>> + *
>> + * We always assume that we can fit in at least PAGE_SIZE in a segment, apart
>> + * from first and last segments.
>> + */
> It took sometime to really understand what is special about the first
> and the last vector. Looks like what we are discussing here is the
> I/O covering a partial page, i.e. the starting offset and the end
> boundary might not cover the whole page.
> 
> It still isn't very clear that why do we need to consider
> queue_logical_block_size(q) and not the PAGE_SIZE for those 2 vectors
> (1. given atomic writes starting offset and length has alignment
> restrictions?
We are using the direct IO alignment restriction, and that is the iovecs 
need to be bdev logical block size aligned - please see 
bdev_iter_is_aligned().

We are also supporting a single iovec currently. As such, the middle 
bvecs will always contain at least PAGE_SIZE, and the first/last must 
have at least LBS data.

Note that we will want to support atomic writes in future for buffered 
IO, but it would be sensible to keep this direct IO alignment 
restriction there as well.

Let me know if this needs to be made clearer in the code/commit message.

Thanks,
John