Re: getdirentries_args and other kernel syscall structures
2005/11/23, Daniel Rudy <[EMAIL PROTECTED]>:
>
> Ok, I'va got a little question here. In the structure
> getdirentries_args, there seems to be duplicated fields that I'm not
> entirely sure what they do. Here's the definition of a structure
> verbatim from sys/sysproto.h:
>
> struct getdirentries_args {
> char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
> char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)];
> char count_l_[PADL_(u_int)]; u_int count; char
> count_r_[PADR_(u_int)];
> char basep_l_[PADL_(long *)]; long * basep; char
> basep_r_[PADR_(long *)];
> };
>
> Now my question is what does the l and r variables do? It seems that
> they do something with padding the data based on the endian of the
> machine? I look through this header file, and I see all the structures
> have similar constructs. Is it something that can be safely ignored
It just pads in the right way (according with endianism) the structure
to the right word. For example, x86 gots sizeof(long *) == 4. If you
want to have a syscall structure like that:
struct example_sys
{
char f;
short p;
int g;
};
it is misaligned. In order to get a proper padded structure (all 32
bits entries) to speed-up accesses to the members, this little trick
is used.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Puzzled about turnstile's lock
> Hi hackers, > I want to understand the current implementation of > turnstile,and meet some questions about its locks' logicality. [snip] It's used to lock td_contested member of struct thread structure and all issues linked to it (as you can see in the source tree). It seems used in a clean way. Attilio turnstile's ``ts_blocked" field is protected by both > ``td_contested" lock and its turnstile_chain lock, but > I think its turnstile_chain lock is enough,because we > allways get the turnstile_chain lock before our manipulation > on ``ts_blocked". > If td_contested lock were needed ,reading ts_blocked is > not protected by td_contested lock,in the kernel source, why? > > Thanks. > -- > Three passions, simple but overwhelmingly strong, have governed my life: > the longing for love, the search for knowledge, and unbearable pity for > the suffering of mankind. > -Bertrand Russell > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rescheduling tasks using swi_add()
2006/1/11, kamal kc <[EMAIL PROTECTED]>: > > dear everybody, > > i had previous thread going on about the cpu load > average. and had some discussion regarding it. i have > a newer thing to discuss on so i started this thread. > > as i mentioned earlier i had put some code in the > bridge.c > that performed compression which took a long time and > hence > i got a high number of interface interrupts (irq22: xl > interrupts). > > so i thought of rescheduling the compression tasks > without > blocking the bridge function. i found this function > swi_add() [snip] swi_* are used to rule interrupt threads but as you're speaking it doesn't seem you're in this case. In order to force a preemption you might use mi_switch(9) which causes a machine-independent context switch for curthread. cheers, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How priority propagation works on read/write lock?
>> This approach fails beacause you need to propagate priority for any
blocking
>> thread for any owners (if needed).
> I'm not sure I follow -- got a simple example?
> A writer won't be able to get the write lock until _all_ of the
> current read lock owners have released the lock. It doesn't
> matter which of the readers you propagate to, eventually all
> of them will have their priority propagated.
>
> On a single CPU system, there is no advantage to propagating
> priority to all of the current readers because only one can
> run at a time. On an SMP system, the disadvantage is that you
> lose the ability for multiple read lock owners to run at the
> same time.
Let's say: threads A, B, C own a read lock (RW1).
After a while:
- A blocks on a write lock (D thread owns)
- B blocks on a read lock (owned by other threads, we say E1, E2, E3)
- C blocks on a mutex (owned by F)
Now if a thread G blocks on RW1 and its priority is higher than A,B,C (which
might have the same priority) priority propagation is needed to hit D, { E1,
E2, E3 } and F. If you just do priority propagation for one of them the
other would not be updated.
turnstiles don't hurts beacause some intrusive lists are defined involving
turnstiles and threads so a sort of "chain" like that:
turnstile->thread->turnstile->thread...
is provided. In the case of multple thread we could have a situation like:
thread1thread1
turnstile->thread2->turnstile--->thread2
thread3->turnstile->thread thread3
And so on.
I did a recursive algorithm for a new primitive (rwblock) which correctly
implements priority propagation for multiple owners mechanism but there are
2 problems:
1) this algorithm is recursive and it's enough hard to change
2) With a new primitive some work of integration between existing
(turnstiles) might be provided.
Currently I'm working on both these problematics and I hope to do something
better next times.
Cheers,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How priority propagation works on read/write lock?
2006/1/18, Daniel Eischen <[EMAIL PROTECTED]>:
>You will eventually do priority propagation for all of them
> (A, B, and C) until G's priority is <= the priority of RW1.
> It doesn't matter if you do one at a time or all of them
> at once. They all (A, B, C) have to release RW1 before
> G can run
You don't point out the problem.
Here the problem is propagating priority to D, {E1, E2, E3} and F. If it
doesn't happen the whole system will starve.
Cheers,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How priority propagation works on read/write lock?
2006/1/18, Daniel Eischen <[EMAIL PROTECTED]>: > I assume we already know how to propagate priority for mutexes, so > once you know how to propagate for RWlocks, it all just works. As I can see, propagate priority for mutex needs a little modify to turnstiles code, that's not a great deal. > Yes, once you choose a thread to propagate, you have to keep > propagating through whatever it is blocked on or until you > reach a point where the propagated priority is <= the priority > of the next thread in the heirarchy. I never questioned that > part of it, just the need to do it for all threads owning the > RW lock at the same time. Maybe it's not "strictly" necessary but please consider that "blocking hierarchies" are never too long and a total priority propagation would be quicker (you however need to propagate to every owner in the end so doing it at the same time could craft a bottleneck if the hierarchy is too long, but it's a rare case and in the opposite way you need to rule 'what thread needs to be update' every time a blocking thread is unblocked). Cheers, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Leak && Free Problem
> We have this section of code: > 1. new_body = api_filter(origin_resp_body,origin_resp_body_len); > 2. origin_resp_body_len = new_body->length; > 3. origin_resp_body = new_body->data; > > I figure that the memory leak is occuring with origin_resp_body being > assigned to the new_body > buffer. But if I try to insert a free(origin_resp_body) between line 1. and > 2. I get the error > "icap_srv in free(): warning: page is already free" when running the program, > or either the error > "free(): warning: junk pointer, too high to make sense" Probabilly (I've not seen the whole code), since new_body and origin_resp_body points to the same chunk, memory is freed passing from new_body. greetings, rookie -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
about gcc code assembly
Hi,
compiling something like:
#include
static int a;
void f() { printf("%d\n", a); }
with:
> gcc -S -o trial.S trial.c
We got:
[snip]
...
.local a
.comm a, 4, 4
.ident "GCC: (GNU) 3.4.2 [FreeBSD] 20040728"
But using .lcomm would not be better? (.lcomm a, 4)
cheers,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
