免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1140 | 回复: 0
打印 上一主题 下一主题

The Linux Kernel's SCSI Subsystem(3) [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2006-06-30 23:41 |只看该作者 |倒序浏览
Where Linux Kernel SCSI Support Stands


Dee-Ann LeBlanc
Tuesday, September 3, 2002 12:14:08 PM
The weakest part of the Linux kernel's SCSI subsystem, most people seem to agree, is the error handling functionality. And yet I was surprised to discover that most SCSI device drivers don't actually make use of error handling, or at least in the formal sense used here. So while the error handler needs a partial or total overhaul, this issue is not necessarily the top one in the SCSI team's "To Do" list.
Actually, I lied, the error handler's Application Program Interface (API) will get an overhaul because right now it is far too unwieldy.
Initial SCSI device initialization, however, is a problem. Not so much on the smaller scale, but on the enterprise scale. When a SCSI device is initialized, a fixed amount of Direct Memory Access (DMA) memory is reserved. DMA allows devices to send data directly to the RAM on your motherboard, and only part of your RAM is set aside by the kernel for DMA use, so this practice can completely overrun your available DMA memory when it comes up against a Storage Area Network (SAN) with thousands of devices.
Another area that stand to be cleaned up is called "tag command queuing." This practice allows multiple SCSI commands to be placed in a specific device's queue, and is only supported by particular SCSI devices. One problem identified in the Linux kernel's SCSI subsystem is that this feature is implemented who knows how many different ways, with each driver handling it how it sees fit. When it comes to computers, one strives to remove such inefficiencies, especially ones where duplicated code at the very least are making kernels and their modules larger. The memory required to load that extra code could certainly be used in smarter ways.
There is a tag command queuing issue, however, that combines with error handling issues and has been plaguing the SCSI team. It is possible for the low level SCSI drivers to be hit with too many commands in rapid succession. When queue is completely filled, a SCSI driver might simply ignore this command or that as it tries to work through its queue, focusing on particular "hot" sections of the drive where many things are taking place. This scenario is called "tag starvation," because a command can end up timing out if it gets ignored for enough seconds, and write speed slowdowns can result.
Of course, all of these queuing issues bring us to the question of how deep a queue actually is. Queue depth is a topic of hot debate, and some feel that there should be a dynamic method of assigning how many commands can wait in a queue, but there is a question regarding whether there is any speed benefit to this. According to some tests, the most performance gains occur when raising the queue depth from one to four slots. After that, benefits level off, getting smaller and smaller with each added entry.


本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u/21323/showart_135004.html
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP