2004年Linux Symposium技术议题概览

10 浏览量更新于2024-07-14 收藏 5.28MB PDF 举报

"这篇文档是2004年Linux Symposium的会议论文集，涵盖了多个与Linux操作系统相关的技术主题。会议在加拿大渥太华举行，日期为7月21日至24日。论文集包含了各种技术文章，涉及网络、内核优化、硬件支持、性能提升、系统启动速度改进以及虚拟化等多个领域。" 在这些技术文章中，我们可以找到以下关键知识点： 1. **TCP连接传递(TCP Connection Passing)**：由Werner Almesberger撰写，可能讨论了如何在Linux环境中高效地传递TCP连接，这可能涉及到网络编程、套接字管理和并发处理。 2. **合作式Linux(Cooperative Linux)**：Dan Aloni的论文，可能介绍了如何在Linux上运行其他操作系统，比如通过合作模式使不同操作系统在同一硬件上并行运行。 3. **构建自己的无线接入点(Build your own Wireless Access Point)**：Erik Andersen的文章，可能涵盖了配置和管理无线网络的技术细节，包括设置热点和无线安全策略。 4. **Linux LSB应用的运行时测试(Run-time testing of LSB Applications)**：Stuart Anderson探讨了Linux标准基(Linux Standard Base)应用程序的测试方法，以确保跨发行版的兼容性。 5. **Linux块I/O现状与未来(Linux Block IO—present and future)**：Jens Axboe的论文深入分析了Linux内核中的块I/O子系统，包括当前实现和未来的改进方向。 6. **Linux AIO性能与企业工作负载的健壮性(Linux AIO Performance and Robustness for Enterprise Workloads)**：Suparna Bhattacharya关注的是异步I/O在Linux下的表现和稳定性，对于高并发和大数据处理环境至关重要。 7. **优化Linux启动时间(Methods to Improve Bootup Time in Linux)**：Tim R. Bird的研究针对如何缩短Linux系统的启动时间，这对于提升用户体验和自动化部署至关重要。 8. **Linux在NUMA系统上的应用(Linux on NUMA Systems)**：Martin J. Bligh讨论了Linux在非统一内存访问(NUMA)架构上的挑战和优化策略，这对于多处理器系统和大型服务器性能至关重要。 9. **通过取消映射页面缓存提高内核性能(Improving Kernel Performance by Unmapping the Page Cache)**：James Bottomley的论文提出了新的优化方法，旨在减少内存开销和提高系统响应速度。 10. **Linux在IBM Power5系统上的虚拟化(Linux Virtualization on IBM Power5 Systems)**：Dave Boutcher的文章介绍了在IBM Power5硬件上运行Linux虚拟机的技术。此外，还有其他如ACPI（高级配置和电源接口）在Linux中的状态、极端环境下Linux的扩展、设备驱动的外置、多处理器和频率调整、动态内核模块支持、网络文件系统NFSv4与安全机制、以及对epoll和select等I/O多路复用机制的比较和评估等内容。这些论文代表了2004年Linux社区的最新研究和技术进展，对于理解Linux系统的内部工作原理和优化技术具有很高的参考价值。

16 • Linux Symposium

for the connection in question by getting the

TCP_MAXICISIZE socket option.

Example:

void *buf;

int ici_size;

size_t size = sizeof(int);

getsockopt(s,SOL_TCP,TCP_MAXICISIZE,

&ici_size,&size);

buf = malloc(ici_size);

size = ici_size;

getsockopt(s,SOL_TCP,TCP_ICI,

buf,&size);

The connection endpoint at the destination is

created by setting the TCP_ICI socket option,

and the connection is activated by “setting”

the TCP_CP_FN socket option to the value

TCPCP_ACTIVATE.

Example:

int sub_function = TCPCP_ACTIVATE;

setsockopt(s,SOL_TCP,TCP_ICI,

buf,size);

/* ... */

setsockopt(s,SOL_TCP,TCP_CP_FN,

&sub_function,

sizeof(sub_function));

3.2 High-level API

These are the most important functions pro-

vided by the high-level API:

void *tcpcp_get(int s);

int tcpcp_size(const void *ici);

int tcpcp_create(const void *ici);

int tcpcp_activate(int s);

The use of a multiplexed socket option is admittedly

ugly, although convenient during development.

tcpcp_get allocates a buffer for the ICI, and

retrieves that ICI (isolating the connection as a

side-effect). The amount of data in the ICI can

be queried by calling tcpcp_size on it.

tcpcp_create sets an ICI on a socket, and

tcpcp_activate activates the connection.

4 Describing a TCP endpoint

In this section, we describe the parameters that

deﬁne a TCP connection and its state. tcpcp

collects all the information it needs to re-create

a TCP connection endpoint in a data structure

we call Internal Connection Information (ICI).

The ICI is portable among systems supporting

tcpcp, irrespective of their CPU architecture.

Besides this data, the kernel maintains a large

number of additional variables that can either

be reset to default values at the destination

(such as congestion control state), or that are

only rarely used and not essential for correct

operation of TCP (such as statistics).

4.1 Connection identiﬁer

Each TCP connection in the global Internet or

any private internet [9] is uniquely identiﬁed by

the IP addresses of the source and destination

host, and the port numbers used at both ends.

tcpcp currently only supports IPv4, but can

be extended to support IPv6, should the need

arise.

4.2 Fixed data

A few parameters of a TCP connection are ne-

gotiated during the initial handshake, and re-

main unchanged during the life time of the

connection. These parameters include whether

window scaling, timestamps, or selective ac-

knowledgments are used, the number of bits by

18 • Linux Symposium

4.5 Timestamps

TCP can use timestamps to detect old segments

with wrapped sequence numbers [10]. This

mechanism is called Protect Against Wrapped

Sequence numbers (PAWS).

Linux uses a global counter (tcp_time_

stamp) to generate local timestamps. If a

moved connection were to use the counter at

the new host, local round-trip-time calculation

may be confused when receiving timestamp

replies from the previous connection, and the

peer’s PAWS algorithm will discard segments

if timestamps appear to have jumped back in

time.

Just turning off timestamps when moving the

connection is not an acceptable solution, even

though [10] seems to allow TCP to just stop

sending timestamps, because doing so would

bring back the problem PAWS tries to solve

in the ﬁrst place, and it would also reduce the

accuracy of round-trip-time estimates, possibly

degrading the throughput of the connection.

A more satisfying solution is to synchroniza-

tion the local timestamp generator. This is

accomplished by introducing a per-connection

timestamp offset that is added to the value

of tcp_time_stamp. This calculation is

hidden in the macro tp_time_stamp(tp),

which just becomes tcp_time_stamp if the

kernel is conﬁgured without tcpcp.

The addition of the timestamp offset is the only

major change tcpcp requires in the existing

TCP/IP stack.

4.6 Receive buffers

There are two buffers at the receiving side:

the buffer containing segments received out-of-

order (see Section 2), and the buffer with data

that is ready for retrieval by the application.

tcpcp currently ignores both buffers: the out-

of-order buffer is copied into the ICI, but not

used when setting up the new socket. Any data

in the receive buffer is left for the application

to read and process.

4.7 Send buffer

The send and retransmit buffer contains data

that is no longer accessible through the socket

API, and that cannot be discarded. It is there-

fore placed in the ICI, and used to populate the

send buffer at the destination.

4.8 Selective acknowledgments

In Section 5 of [11], the use of inbound SACK

information is left optional. tcpcp takes advan-

tage of this, and neither preserves SACK infor-

mation collected from inbound segments, nor

the history of SACK information sent to the

peer.

Outbound SACKs convey information about

the receiver’s out-of-order queue. Fortunately,

[11] declares this information as purely advi-

sory. In particular, if reception of data has been

acknowledged with a SACK, this does not im-

ply that the receiver has to remember having

done so. First, it can request retransmission of

this data, and second, when constructing new

SACKs, the receiver is encouraged to include

information from previous SACKs, but is un-

der no obligation to do so.

Therefore, while [11] discourages losing

SACK information, doing so does not violate

its requirements.

Losing SACK information may temporarily

degrade the throughput of the TCP connec-

tion. This is currently of little concern, be-

cause tcpcp forces the connection into slow

start, which has even more drastic performance

implications.

Linux Symposium 2004 • 19

SACK recovery may need to be reconsid-

ered once tcpcp implements more sophisticated

congestion control.

4.9 Other data

The TCP connection state is currently always

ESTABLISHED. It may be useful to also al-

low passing connections in earlier states, e.g.

SYN_RCVD. This is for further study.

Congestion control data and statistics are cur-

rently omitted. The new connection starts with

slow-start, to allow TCP to discover the char-

acteristics of the new path to the peer.

5 Congestion control

Most of the complexity of TCP is in its conges-

tion control. tcpcp currently avoids touching

congestion control almost entirely, by setting

the destination to slow start.

This is a highly conservative approach that is

appropriate if knowing the characteristics of

the path between the origin and the peer does

not give us any information on the characteris-

tics of the path between the destination and the

peer, as shown in the lower part of Figure 4.

However, if the characteristics of the two paths

can be expected to be very similar, e.g. if the

hosts passing the connection are on the same

LAN, better performance could be achieved by

allowing tcpcp to resume the connection at or

nearly at full speed.

Re-establishing congestion control state is for

further study. To avoid abuse, such an opera-

tion can be made available only to sufﬁciently

trusted applications.

Origin

Destination

Peer

High−speed LAN

WAN

Characteristics may differ

Go to slow−start

Characteristics are identical

Reuse congestion control state

Figure 4: Depending on the structure of the

network, the congestion control state of the

original connection may or may not be reused.

6 Checkpointing

tcpcp is primarily designed for scenarios,

where the old and the new connection owner

are both functional during the process of con-

nection passing.

A similar usage scenario would if the node

owning the connection occasionally retrieves

(“checkpoints”) the momentary state of the

connection, and after failure of the connection

owner, another node would then use the check-

point data to resurrect the connection.

While apparently similar to connection pass-

ing, checkpointing presents several problems

which we discuss in this section. Note that this

is speculative and that the current implementa-

tion of tcpcp does not support any of the exten-

20 • Linux Symposium

sions discussed here.

We consider the send and receive ﬂow of the

TCP connection separately, and we assume that

sequence numbers can be directly translated to

application state (e.g. when transferring a ﬁle,

application state consists only of the actual ﬁle

position, which can be trivially mapped to and

from TCP sequence numbers). Furthermore,

we assume the connection to be in ESTAB-

LISHED state at both ends.

6.1 Outbound data

One or more of the following events may occur

between the last checkpoint and the moment

the connection is resurrected:

• the sender may have enqueued more data

• the receiver may have acknowledged

more data

• the receiver may have retrieved more data,

thereby growing its window

Assuming that no additional data has been re-

ceived from the peer, the new sender can sim-

ply re-transmit the last segment. (Alternatively,

tcp_xmit_probe_skb might be useful for

the same purpose.) In this case, the following

protocol violations can occur:

• The sequence number may have wrapped.

This can be avoided by making sure

that a checkpoint is never older than the

Maximum Segment Lifetime (MSL)

, and

that less than 2

bytes are sent between

checkpoints.

• If using PAWS, the timestamp may be be-

low the last timestamp sent by the old

sender. The best solution for avoiding this

[2] speciﬁes a MSL of two minutes.

is probably to tightly synchronize clock

on the old and the new connection owner,

and to make a conservative estimate of the

number of ticks of the local timestamp

clock that have passed since taking the

checkpoint. This assumes that the times-

tamp clock ticks roughly in real time.

Since new data in the segment sent after res-

urrecting the connection cannot exceed the re-

ceiver’s window, the only possible outcomes

are that the segment contains either new data,

or only old data. In either case, the receiver

will acknowledge the segment.

Upon reception of an acknowledgment, either

in response to the retransmitted segment, or

from a packet in ﬂight at the time when the con-

nection was resurrected, the sender knows how

far the connection state has advanced since the

checkpoint was taken.

If the sequence number from the acknowl-

edgment is below snd_nxt, no special ac-

tion is necessary. If the sequence number is

above snd_nxt, the sender would exception-

ally treat this as a valid acknowledgment.

As a possible performance improvement, the

sender may notify the application once a new

sequence number has been received, and the

application could then skip over unnecessary

data.

6.2 Inbound data

The main problem with checkpointing of in-

coming data is that TCP will acknowledge data

that has not yet been retrieved by the applica-

tion. Therefore, checkpointing would have to

delay outbound acknowledgments until the ap-

plication has actually retrieved them, and has

Note that this exceptional condition does not neces-

sarily have to occur with the ﬁrst acknowledgment re-

ceived.

剩余593页未读，继续阅读

weixin_38741195

粉丝: 2
资源: 970

2004年Linux Symposium技术议题概览

Proceedings of the Linux Symposium

ora-symposium-backend

ora-se-symposium-backend

STOC/FOCS/ITCS/CCC/SODA/ICALP是啥

Usenix Security Symposium

IEEE Symposium on Security and Privacy影响因子

Multi-sensor data fusion for land vehicle localization using RTMAPS[C]// IEEE Intelligent Vehicles Symposium. IEEE.

wordpress漏洞利用工具

BETHENCOURT J, SAHAI A, WATERS B. Ciphertext-policy attribute-based encryption[C]

还有哪些2021年发表的vision transformer 加速器的文献

最新资源