xv6-lab8-lock

最新推荐文章于 2023-01-06 16:14:00 发布
最新推荐文章于 2023-01-06 16:14:00 发布
阅读量2.2k 收藏 34
点赞数 3
分类专栏： 大作业 OS-lab xv6 文章标签： 操作系统
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_25698501/article/details/120997317
版权

Lab:lock

前置知识

  • xv6 book 章节6、3.5、8.1
  • 对于hash的基本认知
  • 对于锁的基本认知以及死锁的处理方法

Memory allocator

实验目标

在未修改前，所有内存块由一个锁管理，若有多个进程并发地获取内存，则会造成非常多的锁等待，kalloctest则统计了锁冲突的次数，如下

$ kalloctest
start test1
test1 results:
--- lock kmem/bcache stats
lock: kmem: #fetch-and-add 83375 #acquire() 433015
lock: bcache: #fetch-and-add 0 #acquire() 1260
--- top 5 contended locks:
lock: kmem: #fetch-and-add 83375 #acquire() 433015
lock: proc: #fetch-and-add 23737 #acquire() 130718
lock: virtio_disk: #fetch-and-add 11159 #acquire() 114
lock: proc: #fetch-and-add 5937 #acquire() 130786
lock: proc: #fetch-and-add 4080 #acquire() 130786
tot= 83375
test1 FAIL

你的目标是修改内存块策略，以减少锁冲突，修改后的锁冲突应该大幅减少，如下

$ kalloctest
start test1
test1 results:
--- lock kmem/bcache stats
lock: kmem: #fetch-and-add 0 #acquire() 42843
lock: kmem: #fetch-and-add 0 #acquire() 198674
lock: kmem: #fetch-and-add 0 #acquire() 191534
lock: bcache: #fetch-and-add 0 #acquire() 1242
--- top 5 contended locks:
lock: proc: #fetch-and-add 43861 #acquire() 117281
lock: virtio_disk: #fetch-and-add 5347 #acquire() 114
lock: proc: #fetch-and-add 4856 #acquire() 117312
lock: proc: #fetch-and-add 4168 #acquire() 117316
lock: proc: #fetch-and-add 2797 #acquire() 117266
tot= 0
test1 OK
start test2
total free number of pages: 32499 (out of 32768)
.....
test2 OK

实验实现

下面我们先看提示

  • 你可以使用kernel/param.h 中的NCPU （NCPU表示XV6使用了几个虚拟处理器，而xv6对于每个进程只有一个线程，该提示表示我们可以基于CPU数量进行修改）
  • 让freerange 将所有空闲内存块给予 正在运行 freerange 的CPU（如果所有空闲内存都给了一个CPU，那么其他CPU怎么办？–从有空闲内存块的CPU拿吗？）
  • 函数 cpuid() 返回当前的 cpu 编号， 不过需要关闭中断才能保证该函数被安全地使用。中断开关可使用 push_off() 和 pop_off()
  • 用 kmem 命名你的锁 （提示我们需要创建额外的锁）

根据以上的提示解读以及我们要解决的主要矛盾—单一内存块管理池与多进程争用内存块之间的矛盾。我们就可以得到大致方案

  • 以 NCPU 为基准，给每一个CPU创建一个内存池
  • 使用锁管理每一个内存池
  • 当某个内存池为空时，从其他内存池偷取内存块

代码实现

/*	kernel/kalloc.c	*/

//首先是多内存池创建和锁管理
//该部分我们只需复用单一内存池，并在初始化时初始化所有锁即可
struct kmem{
  struct spinlock lock;
  struct run *freelist;
};

//用cpuid来分配内存池
struct kmem kmem_sum[NCPU];

void
kinit()
{
  int i;
  //初始化所有锁
  for(i = 0; i < NCPU; ++i)
  {
    initlock(&(kmem_sum[i].lock), "kmem");
  }
  //这里不用修改，默认将内存分配给运行这一函数的cpu
  freerange(end, (void*)PHYSTOP);
}


//kfree本来是将内存块释放到单一内存块中，修改后我们需要放回该cpu对应的内存池
void
kfree(void *pa)
{
  struct run *r;

  if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)
    panic("kfree");

  // Fill with junk to catch dangling refs.
  memset(pa, 1, PGSIZE);

  r = (struct run*)pa;

  push_off();
  int id = cpuid();
  //获取锁以保证内存池的使用安全
  acquire(&(kmem_sum[id].lock));
  r->next = kmem_sum[id].freelist;
  kmem_sum[id].freelist = r;
  release(&(kmem_sum[id].lock));
  pop_off();
}


//内存块获取
void *
kalloc(void)
{
  struct run *r;

  push_off();

  int id = cpuid();

  acquire(&(kmem_sum[id].lock));
    
  r = kmem_sum[id].freelist;
    
  //先从自己的内存池中寻找可用的内存块
  if(r)
  {
    kmem_sum[id].freelist = r->next;
  }
  else	//没有空闲块则从其他内存池中寻找
  {
    int i;
    for(i = 0; i < NCPU; ++i)
    {
      if(i == id) continue;
	  
      //寻找前记得上锁
      acquire(&(kmem_sum[i].lock));

      r = kmem_sum[i].freelist;
      if(r)
      {
        kmem_sum[i].freelist = r->next;
        release(&(kmem_sum[i].lock));
        break;
      }

      release(&(kmem_sum[i].lock));

    }
  }
  release(&(kmem_sum[id].lock));
  pop_off();

  if(r)
    memset((char*)r, 5, PGSIZE); // fill with junk
  return (void*)r;
}

Buffer cache

实验目标

学过计组的我们（bushi）都知道，读磁盘是非常慢的，为了提高磁盘使用效率，系统会将最近使用的磁盘块内容读进cache。在读磁盘块是会先到cache中查找块是否已被缓存，若已缓存则可以直接拿来使用。

在本实验中，cache也面临着同上一个实验一样的问题，单一的cache池与锁管理导致了非常多的锁冲突，如下

$ bcachetest
start test0
test0 results:
--- lock kmem/bcache stats
lock: kmem: #fetch-and-add 0 #acquire() 33035
lock: bcache: #fetch-and-add 16142 #acquire() 65978
--- top 5 contended locks:
lock: virtio_disk: #fetch-and-add 162870 #acquire() 1188
lock: proc: #fetch-and-add 51936 #acquire() 73732
lock: bcache: #fetch-and-add 16142 #acquire() 65978
lock: uart: #fetch-and-add 7505 #acquire() 117
lock: proc: #fetch-and-add 6937 #acquire() 73420
tot= 16142
test0: FAIL
start test1
test1 OK

你的目标是，修改cache管理策略，降低锁冲突，如下

$ bcachetest
start test0
test0 results:
--- lock kmem/bcache stats
lock: kmem: #fetch-and-add 0 #acquire() 32954
lock: kmem: #fetch-and-add 0 #acquire() 75
lock: kmem: #fetch-and-add 0 #acquire() 73
lock: bcache: #fetch-and-add 0 #acquire() 85
lock: bcache.bucket: #fetch-and-add 0 #acquire() 4159
lock: bcache.bucket: #fetch-and-add 0 #acquire() 2118
lock: bcache.bucket: #fetch-and-add 0 #acquire() 4274
lock: bcache.bucket: #fetch-and-add 0 #acquire() 4326
lock: bcache.bucket: #fetch-and-add 0 #acquire() 6334
lock: bcache.bucket: #fetch-and-add 0 #acquire() 6321
lock: bcache.bucket: #fetch-and-add 0 #acquire() 6704
lock: bcache.bucket: #fetch-and-add 0 #acquire() 6696
lock: bcache.bucket: #fetch-and-add 0 #acquire() 7757
lock: bcache.bucket: #fetch-and-add 0 #acquire() 6199
lock: bcache.bucket: #fetch-and-add 0 #acquire() 4136
lock: bcache.bucket: #fetch-and-add 0 #acquire() 4136
lock: bcache.bucket: #fetch-and-add 0 #acquire() 2123
--- top 5 contended locks:
lock: virtio_disk: #fetch-and-add 158235 #acquire() 1193
lock: proc: #fetch-and-add 117563 #acquire() 3708493
lock: proc: #fetch-and-add 65921 #acquire() 3710254
lock: proc: #fetch-and-add 44090 #acquire() 3708607
lock: proc: #fetch-and-add 43252 #acquire() 3708521
tot= 128
test0: OK
start test1
test1 OK

实验实现

接下来依旧先看提示

  • 阅读xv6 book 8.1-8.3 ，了解block cache
  • 可以使用固定大小的bucket，使用素数（如13）来减少哈希冲突 （明示我们使用13个cache池来管理cache）
  • 在哈希表（cache池）中寻找cache并找不到cache时，分配cache必须是原子的（使用锁）
  • 删除所有的cache列表（应该指原来的头插法），使用时间戳替代它来达到LRU算法。因此brelse不需要获取锁（这里没懂）
  • 允许在 bget 中寻找并从其他池子偷窃cache块
  • 你的解决方法可能需要同时持有两个锁（和上一个实验一样的），请确保不会出现死锁
  • 当cache未命中时，你需要寻找一个新的块放到本cache池，请确保不会出现死锁。（这里是指在自己的池子里找到可用的cache，不要二次上锁）
  • 一些debug tips

根据提示以及主要矛盾我们得出一个大概方案

  • 创建一个大小为十三的哈希表，表中元素为cache池。每个池拥有一个锁，保证操作的原子性。

  • cache块根据 blockno 哈希到不同池中。

  • 读取新的磁盘块时，先到对应的cache池中寻找是否已缓存；若无，则先在自己的池中寻找空闲块；若无，则到其他池子寻找空闲块，找到后将该块转移到本池。

  • 为cache块打上时间戳，每次使用时更新，寻找空闲块时，优先选择最久未被使用的空闲块。

  • 块被释放时并不做另外的操作，留在原地。

代码实现

/*	kernel/buf.h	*/
struct buf {
  int valid;   // has data been read from disk?
  ...
  // struct buf *prev; // LRU cache list
  struct buf *next;
  uchar data[BSIZE];
  uint time;
};


/*	kernel/bio.c	*/

/*
	创建哈希表，锁，和hash函数
*/
struct {
  struct spinlock lock[NBUCKET];
  struct buf buf[NBUF];
  struct buf head[NBUCKET];
} bcache;

int hash (int n) {
  return n % NBUCKET;
}

/*
	接下来先解决一堆没那么多操作的函数与
*/

//跟上一实验一样的做法，初始化锁并将所有块挂在第一个池子里
void
binit(void)
{
  struct buf *b;
  
  for (int i = 0; i < NBUCKET; i++) {
    initlock(&(bcache.lock[i]), "bcache.hash");
  }

  bcache.head[0].next = &bcache.buf[0];
  for (b = bcache.buf; b < bcache.buf+NBUF-1; b++) {
    b->next = b+1;
    initsleeplock(&b->lock, "buffer");
  }
  initsleeplock(&b->lock, "buffer");
}

//获取锁，然后将块引用计数-1，并不明白提示所说的不用锁的方法是什么
void
brelse(struct buf *b)
{
  if(!holdingsleep(&b->lock))
    panic("brelse");

  releasesleep(&b->lock);

  int id = hash(b->blockno);
  acquire(&bcache.lock[id]);
  b->refcnt--;  
  release(&bcache.lock[id]);
}

//获取锁，引用计数+1
void
bpin(struct buf *b) {
  int id = hash(b->blockno);
  acquire(&(bcache.lock[id]));
  b->refcnt++;
  release(&(bcache.lock[id]));
}

//获取锁，引用计数-1
void
bunpin(struct buf *b) {
  int id = hash(b->blockno);
  acquire(&(bcache.lock[id]));
  b->refcnt--;
  release(&(bcache.lock[id]));
}


/*
	接下来是比较冗长的一个函数
*/
//辅助函数，用于写cache
void 
write_cache(struct buf *take_buf, uint dev, uint blockno)
{
  take_buf->dev = dev;
  take_buf->blockno = blockno;
  take_buf->valid = 0;
  take_buf->refcnt = 1;
  take_buf->time = ticks;
}

//获取cache
static struct buf*
bget_fir(uint dev, uint blockno)
{

  struct buf *b, *last;
  struct buf *take_buf = 0;
  int id = hash(blockno);
  acquire(&(bcache.lock[id]));

   // 在本池子中寻找是否已缓存，同时寻找空闲块，并记录链表最后一个节点便于待会插入新节点使用
  // Is the block already cached?
  for(b = bcache.head[id].next, last = &(bcache.head[id]); b; b = b->next, last = last->next)
  {

    if(b->dev == dev && b->blockno == blockno)
    {
      b->time = ticks;
      b->refcnt++;
      release(&(bcache.lock[id]));
      acquiresleep(&b->lock);
      return b;
    }
    if(b->refcnt == 0)
    {
      take_buf = b;
    }
  }

  //如果没缓存并且在本池子有空闲块，则使用它
  if(take_buf)
  { 
    write_cache(take_buf, dev, blockno);
    release(&(bcache.lock[id]));
    acquiresleep(&(take_buf->lock));
    return take_buf;
  }

  
 
  // 到其他池子寻找最久未使用的空闲块
  int lock_num = -1;
  
  uint time = __UINT32_MAX__;
  struct buf *tmp;
  struct buf *last_take = 0;
  for(int i = 0; i < NBUCKET; ++i)
  {
    
    if(i == id) continue;
	//获取寻找池子的锁
    acquire(&(bcache.lock[i]));

    for(b = bcache.head[i].next, tmp = &(bcache.head[i]); b; b = b->next,tmp = tmp->next)
    {
      if(b->refcnt == 0)
      {
        //找到符合要求的块
        if(b->time < time)
        {
          
          time = b->time;
          last_take = tmp;
          take_buf = b;
          //如果上一个空闲块不在本轮池子中，则释放那个空闲块的锁		
          if(lock_num != -1 && lock_num != i && holding(&(bcache.lock[lock_num])))
            release(&(bcache.lock[lock_num]));
          lock_num = i;
        }
      }
    }
	//没有用到本轮池子的块，则释放锁
    if(lock_num != i)
      release(&(bcache.lock[i]));
  }
  
  if (!take_buf) 
    panic("bget: no buffers");
  
  //将选中块从其他池子中拿出
  last_take->next = take_buf->next;
  take_buf->next = 0;
  release(&(bcache.lock[lock_num]));
  //将选中块放入本池子中，并写cache
  b = last;
  b->next = take_buf;
  write_cache(take_buf, dev, blockno);


  release(&(bcache.lock[id]));
  acquiresleep(&(take_buf->lock));
  
  return take_buf;
}

该实验到此就结束了


等等！

看着 bget 中频繁地获取锁，最多的时候甚至会同时持有三把锁，是否感觉会有死锁

确实是这样的， bget中获取锁的顺序是不安全的，会出现循环等待

但实验指导中提到

There are some circumstances in which it’s OK if your solution has lock conflicts:

  • When two processes concurrently use the same block number. bcachetest test0 doesn’t ever do this.
  • When two processes concurrently miss in the cache, and need to find an unused block to replace. bcachetest test0 doesn’t ever do this.
  • When two processes concurrently use blocks that conflict in whatever scheme you use to partition the blocks and locks; for example, if two processes use blocks whose block numbers hash to the same slot in a hash table. bcachetest test0 might do this, depending on your design, but you should try to adjust your scheme’s details to avoid conflicts (e.g., change the size of your hash table).

因此上面的代码可以通过测试

下面的代码对获取锁的条件做了限制，试图减少出现死锁的概率（ just for fun）

static struct buf*
bget(uint dev, uint blockno)
{


  // Is the block already cached?
  struct buf *b;
  struct buf *last_b;
  struct buf *take_buf = 0;
  int id = hash(blockno);
  acquire(&bcache.lock[id]);

  for(b = bcache.head[id].next, last_b = &(bcache.head[id]); b; b = b->next, last_b = last_b->next)
  {
    if(b->dev == dev && b->blockno == blockno)
    {
      b->refcnt++;
      release(&bcache.lock[id]);
      acquiresleep(&b->lock);
      return b;
    }
    if(b->refcnt == 0)
    {
      take_buf = b;
    }
  }

  if(take_buf)
  {
    write_cache(take_buf, dev, blockno);
    release(&bcache.lock[id]);
    acquiresleep(&take_buf->lock);
    return take_buf;
  }

  int lock_num = -1;
  uint time = __UINT32_MAX__;
  struct buf *last_take = 0;
  struct buf *tmp;
  
  
  for(int i = 1; i <= NBUCKET/2; ++i)
  {
    int j = id - i >=0 ? id - i : id + (NBUCKET - i);
    // int j = (id + i)%NBUCKET;

    acquire(&bcache.lock[j]);


    for(b = bcache.head[j].next, tmp = &(bcache.head[j]); b; b = b->next, tmp = tmp->next)
    {
      if (b->refcnt == 0) 
      {
        if (b->time < time) 
        {
          time = b->time;
          last_take = tmp;
          take_buf = b;

          if (lock_num != -1 && lock_num != j && holding(&bcache.lock[lock_num])) 
            release(&bcache.lock[lock_num]);

          lock_num = j;
        }   
      }
    }

    if (j!=id && j!=lock_num && holding(&bcache.lock[j])) 
      release(&bcache.lock[j]);
  }

  if (!take_buf) 
    panic("bget: no buffers");

  last_take->next = take_buf->next;
  take_buf->next = 0;
  release(&bcache.lock[lock_num]);


  last_b->next = take_buf;
  take_buf->next = 0;
  write_cache(take_buf, dev, blockno);

  
  release(&bcache.lock[id]);
  acquiresleep(&take_buf->lock);

  return take_buf;


}

该方案在不改变NBUF的前提下无法通过 make grade / Test usertests / test manywrites

逐步增加到 NBUF=MAXOPBLOCKS*12 才能通过

实验结果

请添加图片描述

Wound+=s
关注
  • 3
    点赞
  • 踩
  • 34
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
xv6 6.S081 Lab7: Lock
不定期更新系统使用、编程小技巧，哔哩哔哩账号：https://space.bilibili.com/399455629，欢迎关注
12-23 4681
xv6 6.S081 Lab7: Lock写在前面实验介绍开始！Memory AllocatorBuffer Cache lock代码在这里。本次实验理解起来简单，做起来也容易 写在前面 老样子，在我的博客OS实验xv6 6.S081 开坑中给出了一些有用的参考资料，大家也可以一并参考。 实验介绍 这里是实验指导书。 本次实验主要还是学习内存分配，不过需要注意的是，本实验会和多CPU打交道，因此在内存分配的时候，锁的存在就十分必要了。 本实验主要分为两个部分： 基于多CPU的内存分配器（Memory
xv6 Lab: locks
Holddom的博客
10-22 149
这个实验涉及到内存分配 锁 文件系统 的知识。
XV6 Lab7：Locks
weixin_53215555的博客
12-18 894
bread 返回的buffer会被锁定，而brelse释放锁。buffer缓存。
XV6 Lab8：File System
weixin_53215555的博客
12-18 990
符号链接类似于硬链接，但硬链接仅限于指向同一磁盘上的文件，而符号链接可以跨磁盘设备。增加xv6系统中文件的最大长度，创建一个大小为65803 blocks的文件（发现正好是11+256+256*256，即减少一个直接映射块，修改为二级映射即可）如果标志位O_NOFOLLOW为false，系统调用open应该递归，找到不是软链接的文件将其打开，需要设置一个递归深度上限防止链接的循环。，该标志可用于系统调用open（请注意，传递给open的标志使用位运算符OR，因此新标志不应与任何现有标志重叠）
HW7:xv6 locking
FirMoonLight的博客
12-05 281
要求我们用一句话说明，上述的代码出现的问题。 答：由于在第一次之后，并未就进行了操作，导致第二次的会永远获取不到锁，即死锁。在xv6的代码中，函数会通过指令，屏蔽中断；函数通过指令，将中断打开。但是，如果在的函数中，我们在函数的后面加上指令，而在函数的前面加上指令，并重新编译内核，那么xv6就有可能boot失败，请找出原因。 答： 从下图中可以看出，xv6在的地方被。 在中，依次查找中的值，就可以查出调用栈了，调用栈为： -> -> -> ->-> -> -> -> -> 从调用栈中可以
xv6-labs-2020.tar
04-28
MIT-6.S081的课程源代码xv6-labs-2020
xv6-book-riscv 参考资料
最新发布
03-09
1. xv6-book-riscv-rev1.pdf 2. xv6-参考书翻译-2020版.docx 3. RISC-V手册中文版
xv6-riscv-book-Chinese
03-15
xv6-riscv-book-中文 本项目是MIT 6.S081与6.828课程用书xv6-riscv-book的中文翻译。 此版本翻译基于修改与校对完成，全部内容转为Markdown格式。 如果您在阅读过程中发现翻译中有任何错误或可以改进的地方，欢迎...
xv6-源码.pdf
04-24
Xv6是由麻省理工学院(MIT)为操作系统工程的课程（代号6.828）,开发的一个教学目的的操作系统。Xv6是在x86处理器上(x即指x86)用ANSI标准C重新实现的Unix第六版(Unix V6，通常直接被称为V6)。
xv6-k210:在K210上移植XV6！
03-08
XV6-RISCV在K210上在K210板上运行XV6-RISCV (`-') (`-') <-.(`-') (OO )_.-> _(OO ) __( OO) (_| \_)--.,--.(_/,-.\ ,--. (`-') '-'. ,--. .----. .--. .----. \ `.' / \ \ / (_/ / .' ( OO).-> | .' / \_,-. | /...
xv6---spinlock自旋锁
zion--6135的博客
11-04 426
release一次就减1，直到为0才恢复中断（不一定会打开，需要根据，int old = intr_get()的值判断，old == 1代表acquires spinlock之前中断是打开的，反之用完了锁不打开）。可知：如果在release的时候打开了中断，那么其他cpu会立刻拿到spinlock, 且这个时候已经关闭过了中断，然后中断又被打开了，这肯定不行！进程A：键盘打字---产生中断---acquired 等待spinlock----写入数据。避免编译优化改变代码执行顺序。------>产生死锁。
【xv6 RISC-V】xv6操作系统原理解析与源代码阅读报告
sniper047的博客
06-22 6329
本文具体分析了基于RISC-V多核处理器的xv6操作系统的基本理论与具体实现，通过阅读对应源代码，研究了包括系统调用、陷阱、内存管理、多线程、锁与文件系统等操作系统的重要组成部分，结合mit的lab对其中某些具体实现进行了部分改进。...
CSAPP实验四——cache lab实验（一）
qq_40017011的博客
02-18 5620
void printHelpMenu(){ printf("Usage: ./csim-ref [-hv] -s <num> -E <num> -b <num> -t <file>\n"); printf("Options:\n"); printf(" -h Print this help message.\n"); printf(" -v Optional verbose flag.\n")
[csapp][计组]简单例子理解cache
fmxs
01-06 287
csapp/cachelab/计组的必备知识——cache
Xv6 Locking
clownote
04-09 386
Locking Learning xv6-riscv-book Chapter 5 Locking Concurrency: situations in which multiple instruction sreams are interleaved, due to multiprocessor parallelism, threasd switching, or interrupts. Concurrency control: strategies aimed at correctness und.
6.s081 Lab：locks
pige666的博客
09-22 2134
Lab：locks 1.实验目的 在这个实验中，我们需要重新设计代码以提高并行性。多核计算机上并行性差的一个常见症状是高锁争用。为了减少争用，提高并行性通常需要同时改变数据结构和锁定策略。这需要我们为xv6内存分配器和块缓存执行此操作。 2.实验内容 1）实现每CPU空闲列表，并在一个CPU的列表为空时进行窃取。运行kalloctest查看您的实现是否减少了锁争用，并检查它是否仍然可以分配所有内存。 2）修改块缓存，以便在运行bcachetest时，bcache中所有锁的测试和集数接近于零。理想情况下，块缓
系统调用跟踪-xv6 lab syscall
风雨夕的博客
03-20 6766
1.概述 本文记录xv6操作系统的系统调用跟踪实验，xv6是一个类Unix的简单操作系统。该实验是要求实现一个trace系统调用，该系统调用的功能是根据用户传入的系统调用号跟踪某个或者某些进程的系统调用情况。 2. 实验要求 2.1 实验铺垫 有一个已给出的用户态trace.c程序如下： 复制 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 #inclu
Lab:lock
maoyl0506的博客
09-03 215
lab lock
操作系统-xv6 lab的四道题
mature12的博客
03-16 1457
关于操作系统xv6 lab2020的几道题目 1.Lab: Multithreading 1.1实验背景 1.1.1寄存器 进程在cpu中运行过程中进行切换时，它不会直接把整个进程进行保存和加载，而是通过寄存器的保存和加载实现的，这里我们讨论几种寄存器。 ra寄存器，它保存着程序进入处的值，把进程或者线程比作房子，则寄存器可以理解为进程或线程的“门”。例如是包括进程开始的函数指针。线程/进程切换时可从该处进入程序运行。 sp寄存器时栈顶寄存器，进程初始分配内存是以栈的形式从下往上分配，sp寄存器存放栈顶地址
xv6 lab mmap
08-05
引用和提供了关于xv6 lab mmap的相关代码和提示。xv6 lab mmap是指在xv6操作系统的实验中实现了mmap和munmap系统调用，用于实现文件的内存映射和解除内存映射。mmap函数用于将文件映射到用户进程的虚拟地址空间，并返回映射的起始地址，而munmap函数则用于解除内存映射。在实现mmap时，需要找到用户进程的空闲内存来映射文件，并记录对应的VMA（虚拟内存区域）信息，包括文件指针和引用计数等。当用户进程访问到映射的地址时，会出现缺页异常，需要在trap.c中进行处理，分配物理内存并将文件内容写入其中，完成文件到内存的映射。而在munmap时，需要根据给定的地址找到对应的VMA并解除内存映射，如果有修改过的页面且是MAP_SHARED映射的，则需要将页面的内容写回文件中。此外，还需要修改exit函数，以释放所有mmap的区域，以及修改fork函数，以确保子进程和父进程具有相同的映射区域。提供了对这些实现细节的解读和说明。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值