Re: Why do the CFS chase fairness?
Hi... This would take us back to the days of comp science bachelor seat :) On Sun, Sep 18, 2011 at 01:29, Parmenides mobile.parmeni...@gmail.com wrote: Hi, Current kernel 2.6 have adopted the CFS scheduler which try to ensure that all process can obtain their proportions of allotted processor fairly. I have three questions about it. 1. How to understand unfairness? IMHO, the easiest meaning is that: one task gets proportionally more time slice than the other. Proportion here gets some clue from both process nice level and later from sleep interval. So, technically process with more negative nice level (which means higher priority) gets longer time slice. But that is simply if all processes runs 100% as cpu bound. In reality, some if not all might run as I/O bound, thus it sleeps.The longer a process sleep, when it is awake, it is assumed to be working on something important. Thus it gets temporary priority boost. That's all great, at least on paper. In reality, even such procedure is already aplied in the original O(1) scheduler, the perfomance might suffer in some cases. The problem is still the same, you have N jobs, but have M processors where MN. So, one way or another, unfairness would happen. 2. Why do processes need fairness? Yes, we can argue that now that we human beings need fairness, processes do so. :-) But, are there advantages if the scheduler care about fairness? Just for processes not waiting too long? Or other reasons? To achieve highest response time IMHO. Yes we have preemption, but preemption itself takes time. Fortunately the processor is gettting faster and faster and there was a research that concluded that as long perceived latency is somewhere under ~250-300 milisecond, you would see it as snappy 3. What's the drawbacks of traditional schdulers? According to Love, traditional schedulers assign each process a absolut timeslcie which yields a constant switching rate but variable fairness. How to understand 'constant switching rate'? What does cause 'variable fairness'? I believe Robert Love talks about context switching between processes. Not sure about variable fairness, but I think that's because a program could alternately switch between being CPU bound and I/O bound. In that case, time slices should be dynamically recalculated on every context switch. Also, notice that a process could voluntarily call sched_yield(), thus giving up its time slot. Forgive me if my CS knowledge sucks :) -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regarding mmap synchronization.
Hi, I have mmaped a circular queue buffer created in the kernel. Now I want to mmap the read and write pointers in the queue but I am not sure how to synchronize the access of the pointers between the kernel and userspace(while checking sizes for overflow and underflow). How should I go about doing this? Thanks. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Regarding mmap synchronization.
Hi, On Sun, Sep 18, 2011 at 11:02 AM, mindentropy mindentr...@gmail.com wrote: Hi, I have mmaped a circular queue buffer created in the kernel. Now I want to mmap the read and write pointers in the queue but I am not sure how to synchronize the access of the pointers between the kernel and userspace(while checking sizes for overflow and underflow). How should I go about doing this? The way I normally deal with this is to use 2 indicies, a get index and a put index. One of the indicies if only ever written by kernel space, and the other is only ever written by user space. Normally, I would arrange the get and put pointers to be in uncached memory. If they're in cached memory, I would ensure that they're on different cache lines. You make the circular buffer be a power of 2 in size, and you determine the number of items in the queue by subtracting the get index from the put index. To retrieve the items from the queue, you apply a mask. Lets say you're using 32-bit indicies and you have a max of 512 items in the queue. You would mask the index with ~0x1FF in order to determine the real index value. If the items in the circular buffer are in cached memory, then I normally try to make each item be an exact multiple of the cache line size. I find using uncached memory is generally better for this type of thing (the accesses are slower, but may be faster after accounting for the cache management). If you want to communicate in both directions, then you create a separate queue for each direction. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Cannot read using USB Skeleton Driver
Just do: modprobe usb_serial vendor=0x product=0x with the proper vendor and product ids for your device, then plug it in. No kernel changes needed at all, just have a pair of bulk in/out endpoints and all will work automatically for you. Thanks Greg, I had thought that the usbserial driver would only work with proper CDC class virtual COM devices. I compiled it and tried it on my device and it worked fine! I was able to do bidirectional communication. So at least now I can be sure that one end is working. But the same device with the same firmware still doesn't work with the (customized) usb-skeleton. What could be wrong? Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
