How does dokany work in more than 100 threads? help me.

[zofoc]

Is the maximum value of threadcount 64? I modify dokan myself DOKAN_MAX_THREAD becomes 127 and recompiled. After running, the threadcount is 64 too. Is this a limitation of the dokany driver kernel? Do I want the dokang worker thread to be greater than 100? How to operate.thank you

[Liryna]

Hi @zofoc ,

There is no limitation. Are you sure the new library was used when running your test? Try to print ThreadCount here https://github.com/dokan-dev/dokany/blob/31f8381e1efc207e7c02bdea0a47c819e9810c3f/dokan/dokan.c#L235

If you want to handle more request at a time, you might be interested to contribute to this feature: https://github.com/dokan-dev/dokany/issues/981

[zofoc]

Hi @zofoc ,

There is no limitation. Are you sure the new library was used when running your test? Try to print ThreadCount here

https://github.com/dokan-dev/dokany/blob/31f8381e1efc207e7c02bdea0a47c819e9810c3f/dokan/dokan.c#L235

If you want to handle more request at a time, you might be interested to contribute to this feature: #981

Yes.I'm sure that the new library I recompiled was used .but ThreadCount is 64 too. I set DokanOptions->ThreadCount =127 Directly .but ThreadCount is 64 too. Are there any details I haven't done well

[Liryna]

@zofoc How do you see that there is only 64 thread if it is set to 127 ? There is no logic outside the function I pointed. It should be easy to have it set to 127.

[zofoc]

I saw in Windows Resource Monitor( at the option CPU , my application's threadcount is 64 when i set the /t more than 64). Is my understanding wrong? My application involves high-frequency random 4K access of more than 5000 50g files, and often 10-50 files are read for more than 5 seconds. So I want to see if I can improve the random reading performance by setting threadcount so that they can read it in 5 seconds.

[Liryna]

@zofoc Could you share the code with the log that prints the number of threads as I pointed and a screenshot of the log being printer ?

[zofoc]

In the latest 1.5.0.3, is there any implementation details of the core driver including the option allowipcbatching? Is this option possible to improve the performance of my application environment?

[Liryna]

It is really an option that is here to improve the type of situation you have described. Yes the latest version has the option in the kernel side. It is only the library that needs to be adapted to support it.

[zofoc]

I'm outside now. I'll go back later and have a look at the log details. My application does not read 5000 files every time. It reads 1000 files randomly. But there are 10-50 random reads with a time of more than 5 seconds. My disks are M2 Interface High-Speed disks. It is reasonable that there should not be so many files read for more than 5 seconds.

[zofoc]

What is the kernel driver implementation of the allowipcbatching option? No implementation details on the library? So now I can't set this option to achieve the effect?

[Liryna]

Exact the feature does not exist in the library and need someone to look into it.

[zofoc]

After looking at the code, I finally found that waitformultipleobjects cannot wait for more than 64 kernel objects, so it is unrealistic to improve the performance described by me through this method

[zofoc]

Exact the feature does not exist in the library and need someone to look into it.

It is expected that there will be masters to realize this function in the library.

[Liryna]

Thanks for the feedback 😊