Just another WordPress.com weblog
NFV Approaches Phase 2, With Help from the Linux Foundation
ETSI는 코드를 만들어내지 않지만, 이제 대략적으로 뭘 원하는 지 정리가 되었으니(아직 NFV Group Specifciation 업데이트 된 게 나와야겠지만) 실제 동작하는 코드가 필요하다고. OpenDayLight(ODL)이 그랬던 것처럼 실제로 동작하는 Reference code가 있어야 개발 속도를 높일 수 있다. 문제(?)는 ODL이 그랬던 것처럼 하나의 reference system이 만들어지면 그 reference system과는 다른 것들은 모두 죽어버린다는 것.
이번에도 Linux Foundation이 실질적인 리드를 하기 위해 7/1일에 AT&T, HP, Intel, Linux Foundation 담당자들이 모였다고 한다.Open Source NFV Plans
2.4에서는 unsolicited ARP reply 수신 여부를 커널 빌드 옵션으로 결정했지만 2.6에서는 proc의 arp_accept 값으로 선택할 수 있다.
kernel 2.4
#ifdef CONFIG_IP_ACCEPT_UNSOLICITED_ARP
/* Unsolicited ARP is not accepted by default.
It is possible, that this option should be enabled for some
devices (strip is candidate)
*/
if (n == NULL &&
arp->ar_op == htons(ARPOP_REPLY) &&
inet_addr_type(sip) == RTN_UNICAST)
n = __neigh_lookup(&arp_tbl, &sip, dev, -1);
#endif
kernel 2.6
if (ipv4_devconf.arp_accept) {
/* Unsolicited ARP is not accepted by default.
It is possible, that this option should be enabled for some
devices (strip is candidate)
*/
if (n == NULL &&
arp->ar_op == htons(ARPOP_REPLY) &&
inet_addr_type(sip VRF_CALL_ARG(dev->vrf)) == RTN_UNICAST)
n = __neigh_lookup(&arp_tbl, &sip, dev, 1);
}
ioctl(), the big kernel lock, and 32-bit compatibility [LWN.net].
예전에 구현된 ioctl 자체가 BKL(Big Kernel Lock, lock_kernel())을 걸기 때문에 만일 실행되는 ioctl handler가 시간을 많이 소요하면 전체 프로세스들이 커널을 이용하지 못한다는 의미.
Single processor 환경에서는 kernel context로 들어간 순간 어차피 동작할 수 있는 user process가 없으므로 의미가 없지만, multi-processor에서는 상황이 다르다.
좀더 자세히 보면 fs의 method중 ioctl이 삭제되고 unlocked_ioctl로 대체되었다. 그리고 application에서 ioctl을 호출하면 해당 fs의 unlocked_ioctl을 호출한다.
static long vfs_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
int error = -ENOTTY;
if (!filp->f_op || !filp->f_op->unlocked_ioctl)
goto out;
error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
if (error == -ENOIOCTLCMD)
error = -EINVAL;
out:
return error;
}
XFRM is located deep within the kernel and it isn’t directly visible to the programmer. It is also an undocumented part of the kernel. The standard way of the communication with XFRM is done trough the Netlink Sockets API which is the standard IPC mechanism for various parts of the kernel. More specifically, the part of Netlink of our interest is NETLINK_XFRM. Unfortunately, that part is complex and also undocumented. An additional API does exist. It is called rtnetlink and is a wrapper API for netlink. It is somewhat easier to use and it is somewhat documented. It is a part of iproute2 project
linux buffer management를 보다보니 slab이란 용어가 나옴.
예전에 용책임이 slab이란 말을 했고, 리눅스에서 메모리 확인할 때 slab info를 쓴다는 말을 들었는데 그게 뭘까 해서 찾아 봄.
slab은 커널 내부에서 메모리 관리를 할때 사용하는 방식.
– slab는 일반적인 메모리 관리 layer
– slab은 여러개의 cache로 이루어지는데 각각의 cache는 cache되는 object type 마다 1개씩 존재함. 즉 inode용 cache, skbuffer용 cache 등..
– 하나의 cache는 1개 혹은 그 이상의 물리적으로 연속된 page로 구성됨. 대개 1개 임.
-> 이렇게 때문에 memory fragmentation이 발생하지 않는다고 하는데 아마도 fragmentation의 기준을 page로 삼기 때문이 아닌가 싶음. 좀 더 확인 필요.
– cache마다 full, partial, empty등의 속성이 있어 메모리 할당이 요구되는 경우 partial 혹은 empty에서 할당됨
– 2.2 부터 memory fragmentation을 처리하기 위해 도입됨.
-> 그 전에는 buddy system으로 구성됨. 그러나 작은 크기의 데이터할당이 많은 경우 buddy system은 internal fragmentation 문제를 가짐.
– vmstat -m
* Internal fragmentation : 실제 필요한 것보다 많이 할당해서 낭비되는 경우. 예를 들어 buffer의 크기를 무조건 2K씩 할당하는 경우 2K보다 작은 경우는 (2k – 실제 데이터 크기) 만큼의 낭비가 발생한다.
* External fragmentation : 실제 메모리 공간에서 남아 있는 공간의 합은 충분하지만 할당되지 않은 공간들이 여러 곳에 산재해 있어 하나의 버퍼로 사용될 수 없는 경우.
학교 다닐 때 공부했던 단어를 다시 들으니 기분이 ..
Buddy system
참고
Linux kernel Development
http://kerneltrap.org/node/5336 budy and slab allocators.
http://www.linuxworld.com.au/article/189774/slab_defragmentation?fp=4194304&fpid=1 slab defragmentation
http://en.wikipedia.org/wiki/Slab_allocation
Life goes on 