Hi Miklos,
thanks for the quick reply.
On 4/2/25 20:29, Miklos Szeredi wrote:
> On Wed, 2 Apr 2025 at 19:41, Bernd Schubert <bschubert@xxxxxxx> wrote:
>>
>> No need to take lock, we can have that in atomic way.
>> fuse-io-uring and virtiofs especially benefit from it
>> as they don't need the fiq lock at all.
>
> This is good.
>
> It would be even better to have per-cpu counters, each initialized to
> a cpuid * FUSE_REQ_ID_STEP and jumping by NR_CPU * FUSE_REQ_ID_STEP.
>
> Hmm?
/**
* Get the next unique ID for a request
*/
static inline u64 fuse_get_unique(struct fuse_iqueue *fiq)
{
int step = FUSE_REQ_ID_STEP * (task_cpu(current) + 1);
u64 cntr = this_cpu_inc_return(*fiq->reqctr);
return cntr * step;
}
passthrough_hp-10113 [028] ...1. 79978.381908: fuse_request_bg_enqueue: connection 43 req 58 opcode 26 (FUSE_INIT) len 0
passthrough_hp-10113 [028] ...2. 79978.382032: fuse_request_enqueue: connection 43 req 58 opcode 26 (FUSE_INIT) len 104
fuse_worker-10115 [008] ...1. 79978.485348: fuse_request_send: connection 43 req 58 opcode 26 (FUSE_INIT) len 104
fuse_worker-10115 [008] ...1. 79978.489948: fuse_request_end: connection 43 req 58 len 80 error 0
df-10153 [012] ...1. 79981.776173: fuse_request_enqueue: connection 43 req 26 opcode 3 (FUSE_GETATTR) len 56
fuse-ring-12-10131 [012] ...1. 79981.776345: fuse_request_send: connection 43 req 26 opcode 3 (FUSE_GETATTR) len 56
fuse-ring-12-10131 [012] ...1. 79981.776628: fuse_request_end: connection 43 req 26 len 56 error 0
df-10153 [012] ...1. 79981.778866: fuse_request_enqueue: connection 43 req 52 opcode 17 (FUSE_STATFS) len 40
fuse-ring-12-10131 [012] ...1. 79981.778887: fuse_request_send: connection 43 req 52 opcode 17 (FUSE_STATFS) len 40
fuse-ring-12-10131 [012] ...1. 79981.779050: fuse_request_end: connection 43 req 52 len 40 error 0
ls-10154 [013] ...1. 79986.145078: fuse_request_enqueue: connection 43 req 28 opcode 22 (FUSE_GETXATTR) len 65
fuse-ring-13-10132 [013] ...1. 79986.145440: fuse_request_send: connection 43 req 28 opcode 22 (FUSE_GETXATTR) len 65
fuse-ring-13-10132 [013] ...1. 79986.146932: fuse_request_end: connection 43 req 28 len 65 error -95
ls-10154 [013] ...1. 79986.147172: fuse_request_enqueue: connection 43 req 56 opcode 22 (FUSE_GETXATTR) len 72
fuse-ring-13-10132 [013] ...1. 79986.147219: fuse_request_send: connection 43 req 56 opcode 22 (FUSE_GETXATTR) len 72
fuse-ring-13-10132 [013] ...1. 79986.148048: fuse_request_end: connection 43 req 56 len 72 error -95
ls-10154 [013] ...1. 79986.152345: fuse_request_enqueue: connection 43 req 84 opcode 27 (FUSE_OPENDIR) len 48
fuse-ring-13-10132 [013] ...1. 79986.152385: fuse_request_send: connection 43 req 84 opcode 27 (FUSE_OPENDIR) len 48
fuse-ring-13-10132 [013] ...1. 79986.153214: fuse_request_end: connection 43 req 84 len 48 error 0
ls-10154 [013] ...1. 79986.154291: fuse_request_enqueue: connection 43 req 112 opcode 44 (FUSE_READDIRPLUS) len 80
fuse-ring-13-10132 [013] ...1. 79986.154405: fuse_request_send: connection 43 req 112 opcode 44 (FUSE_READDIRPLUS) len 80
fuse-ring-13-10132 [013] ...1. 79986.171515: fuse_request_end: connection 43 req 112 len 80 error 0
ls-10154 [013] ...1. 79986.174221: fuse_request_enqueue: connection 43 req 140 opcode 44 (FUSE_READDIRPLUS) len 80
fuse-ring-13-10132 [013] ...1. 79986.174264: fuse_request_send: connection 43 req 140 opcode 44 (FUSE_READDIRPLUS) len 80
fuse-ring-13-10132 [013] ...1. 79986.174510: fuse_request_end: connection 43 req 140 len 80 error 0
ls-10154 [013] ...1. 79986.174739: fuse_request_bg_enqueue: connection 43 req 168 opcode 29 (FUSE_RELEASEDIR) len 0
fuse-ring-13-10132 [013] ...1. 79986.179691: fuse_request_send: connection 43 req 168 opcode 29 (FUSE_RELEASEDIR) len 64
fuse-ring-13-10132 [013] ...1. 79986.180011: fuse_request_end: connection 43 req 168 len 64 error 0
Slight issue is that request IDs now have quite an up down,
even more than patch 2/4. Ok with you?
Thanks,
Bernd
