Linux：在线程中进行像 fadvise 这样的系统调用的最具可扩展性的设计是什么？
我的服务器有以下要求：
1）每个到服务器的新连接都会触发一系列 N posix_fadvise 调用。 2) 每个连接的前几个 fadvise 调用应该尽快发生 3) 如果客户端发出以下请求，则能够重新排序 fadvise 调用 后续请求。
我在想：带有共享队列的线程池，其中线程池大小约为 100。还有其他建议吗？
My server has the following requirements:
1) each new connection to the server will trigger a series of N posix_fadvise calls.
2) the first few fadvise calls per connection should happen ASAP
3) ability to re-order the fadvise calls if the client makes a
subsequent requests.
I am thinking: thread pool with shared queue, where thread pool size is ~100. Any other suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
假设您正在谈论
POSIX_FADV_WILLNEED：posix_fadvise已经是异步的。也就是说，它启动内核机制以在后台开始对数据进行分页，但它实际上并不等待读取任何数据。它立即返回。换句话说，posix_fadvise 已经是一种并发机制，因此生成您自己的线程来调用它是没有意义的。并且无法“重新排序”调用，因为一旦将它们交给内核，内核将自行决定如何重新排序磁盘访问。
如果你真的想自己动手，只需让你的线程一遍又一遍地进行阻塞 read() 调用来读取小块（例如 8k）。 （也就是说，重复按顺序读入同一个 8k 缓冲区。使用同一个缓冲区会将其保留在 L1 缓存中，并避免不必要地破坏内存总线。）这将填充页面缓存，并让您在发生这种情况时获得一些控制。
不过，我有点怀疑您的应用程序是否需要这样的机制......
Assuming you are talking about
POSIX_FADV_WILLNEED:posix_fadviseis already asynchronous. That is, it fires off the kernel's machinery to start paging in data in the background, but it does not actually wait for any data to get read. It returns immediately.In other words,
posix_fadviseis already a concurrency mechanism, so spawning your own threads to invoke it is non-sensical. And there is no way to "re-order" the calls, because once they have been handed to the kernel, the kernel will make up its own mind about how to re-order the disk accesses.If you really want to roll your own, just have your threads making blocking read() calls over and over to read small-ish blocks (like 8k). (That is, read sequentially into the same 8k buffer repeatedly. Using the same buffer will keep it in L1 cache and avoid hammering the memory bus needlessly.) That will populate the page cache and give you some control over when it happens.
I am a little skeptical that your application needs such a mechanism, though...
对于同一个底层设备，在
fadvise中同时阻塞多个线程是没有意义的，因为无论如何它们都共享相同的请求队列。这意味着您应该只需要一个预读线程，它从队列中获取预读请求并按顺序执行它们。
There is no point in having multiple threads blocking in
fadviseat the same time for the same underlying device, since they're all sharing the same request queue anyway.This means that you should only need a single readahead thread, that takes readahead requests from a queue and executes them sequentially.