Hi, Everyone on lkml
I am read linux scheduler at home in last vacation.
After read , I have some question that want to consult:
1.
In schedule() function, we can find some code like this:
if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
switch_count = &prev->nvcsw;
if (unlikely((prev->state & TASK_INTERRUPTIBLE) &&
unlikely(signal_pending(prev))))
prev->state = TASK_RUNNING;
else {
if (prev->state == TASK_UNINTERRUPTIBLE)
rq->nr_uninterruptible++;
deactivate_task(prev, rq);
}
}
I think I can understand code in two braces: they want to change
status of task which have signal pending when sleep, or remove task
that is 'deep sleeping' from ready queue.
but my question is why we do not need such code (in both braces)
when preempt is enable?
2. in scheduler_tick()
Before split time slice, we should be check some conditions first, these
check code is copied here:
/*
* Prevent a too long timeslice allowing a task to
monopolize
* the CPU. We do this by splitting up the timeslice into
* smaller pieces.
*
* Note: this does not mean the task's timeslices expire or
* get lost in any way, they just might be preempted by
* another task of equal priority. (one with higher
* priority would have preempted this task already.) We
* requeue this task to the end of the list on this priority
* level, which is in essence a round-robin of tasks with
* equal priority.
*
* This only applies to tasks in the interactive
* delta range with at least TIMESLICE_GRANULARITY to
requeue.
*/
if (TASK_INTERACTIVE(p) && !((task_timeslice(p) -
p->time_slice) % TIMESLICE_GRANULARITY(p)) &&
(p->time_slice >= TIMESLICE_GRANULARITY(p)) &&
(p->array == rq->active)) {
requeue_task(p, rq->active);
set_tsk_need_resched(p);
}
My second question is , what's mean of
(task_timeslice(p) - p->time_slice) % TIMESLICE_GRANULARITY(p)
??
Thanks in advanced.
sailor
On Sat, 8 Oct 2005, liyu wrote:
> Hi, Everyone on lkml
Hi Liyu,
>
> I am read linux scheduler at home in last vacation.
>
> After read , I have some question that want to consult:
>
> 1.
>
> In schedule() function, we can find some code like this:
>
>
> if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
> switch_count = &prev->nvcsw;
> if (unlikely((prev->state & TASK_INTERRUPTIBLE) &&
> unlikely(signal_pending(prev))))
> prev->state = TASK_RUNNING;
> else {
> if (prev->state == TASK_UNINTERRUPTIBLE)
> rq->nr_uninterruptible++;
> deactivate_task(prev, rq);
> }
> }
>
> I think I can understand code in two braces: they want to change
> status of task which have signal pending when sleep, or remove task
> that is 'deep sleeping' from ready queue.
> but my question is why we do not need such code (in both braces)
> when preempt is enable?
I'm sorry I don't quite understand your question, but I can at least
explain the logic of what is happening.
The first "if" is entered if the prev task is in something other than the
TASK_RUNNING state (which is zero). It also has to not have the
PREEMPT_ACTIVE set. The next "if" checks to see if the prev task is in
the TASK_INTERRUPTIBLE state and has a signal pending. Which the
TASK_INTERRUPTIBLE state allows to be woken up on signals.
If there is no signal or the task is sleeping other than
TASK_INTERRUPTIBLE then the task is taken off the run queue.
Now the reason for the check against PREEMPT_ACTIVE is very important
here. If PREEMPT_ACTIVE is set, then that means that the task was
preempted by something else and did _not_ call schedule directly. Code
that usually sets current to something other than TASK_RUNNING usually has
logic around it to test if it should call schedule and be taken off the
run queue. If PREEMPT_ACTIVE is set, then that means you don't know where
in this logic the task was preempted. If you take it off the run queue
now, it may not have been in a position to ever wake up. So you don't
ever want a preemption to take a task off the run queue. Only when the
task implicitly calls schedule.
>
>
> 2. in scheduler_tick()
>
> Before split time slice, we should be check some conditions first, these
> check code is copied here:
>
> /*
> * Prevent a too long timeslice allowing a task to
> monopolize
> * the CPU. We do this by splitting up the timeslice into
> * smaller pieces.
> *
> * Note: this does not mean the task's timeslices expire or
> * get lost in any way, they just might be preempted by
> * another task of equal priority. (one with higher
> * priority would have preempted this task already.) We
> * requeue this task to the end of the list on this priority
> * level, which is in essence a round-robin of tasks with
> * equal priority.
> *
> * This only applies to tasks in the interactive
> * delta range with at least TIMESLICE_GRANULARITY to
> requeue.
> */
> if (TASK_INTERACTIVE(p) && !((task_timeslice(p) -
> p->time_slice) % TIMESLICE_GRANULARITY(p)) &&
> (p->time_slice >= TIMESLICE_GRANULARITY(p)) &&
> (p->array == rq->active)) {
>
>
> requeue_task(p, rq->active);
> set_tsk_need_resched(p);
> }
>
> My second question is , what's mean of
>
> (task_timeslice(p) - p->time_slice) % TIMESLICE_GRANULARITY(p)
>
Sorry, I'm not about to even think about what Ingo's doing here ;-) I just
trust Ingo knows what he's doing.
You need to ask Ingo himself.
-- Steve
On 10/9/05, Steven Rostedt <[email protected]> wrote:
>
> On Sat, 8 Oct 2005, liyu wrote:
>
> > Hi, Everyone on lkml
>
> Hi Liyu,
>
> >
> > I am read linux scheduler at home in last vacation.
> >
> > After read , I have some question that want to consult:
> >
> > 1.
> >
> > In schedule() function, we can find some code like this:
> >
> >
> > if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
> > switch_count = &prev->nvcsw;
> > if (unlikely((prev->state & TASK_INTERRUPTIBLE) &&
> > unlikely(signal_pending(prev))))
> > prev->state = TASK_RUNNING;
> > else {
> > if (prev->state == TASK_UNINTERRUPTIBLE)
> > rq->nr_uninterruptible++;
> > deactivate_task(prev, rq);
> > }
> > }
> >
> > I think I can understand code in two braces: they want to change
> > status of task which have signal pending when sleep, or remove task
> > that is 'deep sleeping' from ready queue.
> > but my question is why we do not need such code (in both braces)
> > when preempt is enable?
>
> I'm sorry I don't quite understand your question, but I can at least
> explain the logic of what is happening.
>
> The first "if" is entered if the prev task is in something other than the
> TASK_RUNNING state (which is zero). It also has to not have the
> PREEMPT_ACTIVE set. The next "if" checks to see if the prev task is in
> the TASK_INTERRUPTIBLE state and has a signal pending. Which the
> TASK_INTERRUPTIBLE state allows to be woken up on signals.
>
> If there is no signal or the task is sleeping other than
> TASK_INTERRUPTIBLE then the task is taken off the run queue.
>
> Now the reason for the check against PREEMPT_ACTIVE is very important
> here. If PREEMPT_ACTIVE is set, then that means that the task was
> preempted by something else and did _not_ call schedule directly. Code
> that usually sets current to something other than TASK_RUNNING usually has
> logic around it to test if it should call schedule and be taken off the
> run queue. If PREEMPT_ACTIVE is set, then that means you don't know where
> in this logic the task was preempted. If you take it off the run queue
> now, it may not have been in a position to ever wake up. So you don't
> ever want a preemption to take a task off the run queue. Only when the
> task implicitly calls schedule.
>
> >
> >
> > 2. in scheduler_tick()
> >
> > Before split time slice, we should be check some conditions first, these
> > check code is copied here:
> >
> > /*
> > * Prevent a too long timeslice allowing a task to
> > monopolize
> > * the CPU. We do this by splitting up the timeslice into
> > * smaller pieces.
> > *
> > * Note: this does not mean the task's timeslices expire or
> > * get lost in any way, they just might be preempted by
> > * another task of equal priority. (one with higher
> > * priority would have preempted this task already.) We
> > * requeue this task to the end of the list on this priority
> > * level, which is in essence a round-robin of tasks with
> > * equal priority.
> > *
> > * This only applies to tasks in the interactive
> > * delta range with at least TIMESLICE_GRANULARITY to
> > requeue.
> > */
> > if (TASK_INTERACTIVE(p) && !((task_timeslice(p) -
> > p->time_slice) % TIMESLICE_GRANULARITY(p)) &&
> > (p->time_slice >= TIMESLICE_GRANULARITY(p)) &&
> > (p->array == rq->active)) {
> >
> >
> > requeue_task(p, rq->active);
> > set_tsk_need_resched(p);
> > }
> >
> > My second question is , what's mean of
> >
> > (task_timeslice(p) - p->time_slice) % TIMESLICE_GRANULARITY(p)
> >
>
> Sorry, I'm not about to even think about what Ingo's doing here ;-) I just
> trust Ingo knows what he's doing.
>
> You need to ask Ingo himself.
>
Hmmm... basic working is: assume that task P and Q are interactive,
and at the start of the scheduling cycle, both P and Q have got 200
slices to burn, and also that TIMESLICE_GRANULARITY is 50 for P and
100 for Q. Then, by starting to schedule P first, P would run for 50
cycles, Q for 100, P for 50, Q for 100 and P for 50 + 50.
Please note that there are probably more details to take acount of,
but basic logic is that given some tasks with same priority, they
don't use all their slice in one go but take turns in using it.
Probably the granilarity is related to static priority, dynamic
priority, interactive stimation or whatever else control feature.
--
Greetz, Antonio Vargas aka winden of network
http://wind.codepixel.com/
Every day, every year
you have to work
you have to study
you have to scene.
Steven Rostedt Wrote:
>On Sat, 8 Oct 2005, liyu wrote:
>
>
>
>>Hi, Everyone on lkml
>>
>>
>
>Hi Liyu,
>
>
>
>> I am read linux scheduler at home in last vacation.
>>
>> After read , I have some question that want to consult:
>>
>> 1.
>>
>> In schedule() function, we can find some code like this:
>>
>>
>> if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
>> switch_count = &prev->nvcsw;
>> if (unlikely((prev->state & TASK_INTERRUPTIBLE) &&
>> unlikely(signal_pending(prev))))
>> prev->state = TASK_RUNNING;
>> else {
>> if (prev->state == TASK_UNINTERRUPTIBLE)
>> rq->nr_uninterruptible++;
>> deactivate_task(prev, rq);
>> }
>> }
>>
>> I think I can understand code in two braces: they want to change
>>status of task which have signal pending when sleep, or remove task
>>that is 'deep sleeping' from ready queue.
>> but my question is why we do not need such code (in both braces)
>>when preempt is enable?
>>
>>
>
>I'm sorry I don't quite understand your question, but I can at least
>explain the logic of what is happening.
>
>The first "if" is entered if the prev task is in something other than the
>TASK_RUNNING state (which is zero). It also has to not have the
>PREEMPT_ACTIVE set. The next "if" checks to see if the prev task is in
>the TASK_INTERRUPTIBLE state and has a signal pending. Which the
>TASK_INTERRUPTIBLE state allows to be woken up on signals.
>
>If there is no signal or the task is sleeping other than
>TASK_INTERRUPTIBLE then the task is taken off the run queue.
>
>Now the reason for the check against PREEMPT_ACTIVE is very important
>here. If PREEMPT_ACTIVE is set, then that means that the task was
>preempted by something else and did _not_ call schedule directly. Code
>that usually sets current to something other than TASK_RUNNING usually has
>logic around it to test if it should call schedule and be taken off the
>run queue. If PREEMPT_ACTIVE is set, then that means you don't know where
>in this logic the task was preempted. If you take it off the run queue
>now, it may not have been in a position to ever wake up. So you don't
>ever want a preemption to take a task off the run queue. Only when the
>task implicitly calls schedule.
>
>
>
>> 2. in scheduler_tick()
>>
>> Before split time slice, we should be check some conditions first, these
>>check code is copied here:
>>
>> /*
>> * Prevent a too long timeslice allowing a task to
>>monopolize
>> * the CPU. We do this by splitting up the timeslice into
>> * smaller pieces.
>> *
>> * Note: this does not mean the task's timeslices expire or
>> * get lost in any way, they just might be preempted by
>> * another task of equal priority. (one with higher
>> * priority would have preempted this task already.) We
>> * requeue this task to the end of the list on this priority
>> * level, which is in essence a round-robin of tasks with
>> * equal priority.
>> *
>> * This only applies to tasks in the interactive
>> * delta range with at least TIMESLICE_GRANULARITY to
>>requeue.
>> */
>> if (TASK_INTERACTIVE(p) && !((task_timeslice(p) -
>> p->time_slice) % TIMESLICE_GRANULARITY(p)) &&
>> (p->time_slice >= TIMESLICE_GRANULARITY(p)) &&
>> (p->array == rq->active)) {
>>
>>
>> requeue_task(p, rq->active);
>> set_tsk_need_resched(p);
>> }
>>
>> My second question is , what's mean of
>>
>> (task_timeslice(p) - p->time_slice) % TIMESLICE_GRANULARITY(p)
>>
>>
>>
>
>Sorry, I'm not about to even think about what Ingo's doing here ;-) I just
>trust Ingo knows what he's doing.
>
>You need to ask Ingo himself.
>
>-- Steve
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Thanks a lot for your reply first, to Steven especially.
For second question, a my friend reply me, but his reply wrote by chinese.
I try translate them here, they may be not very exactly.
((task_timeslice(p) - p->time_slice) % TIMESLICE_GRANULARITY(p))
It just is 'preempt-point', the time interval of preempt-point vary by circumstances of task run.
, IOW, the result of TIMESLICE_GRANULARITY(p) is different at each clock interrput. it have
related to task-->sleep_avg, SMP and total of CPU.
In general, if HZ equal 100, then
TIMESLICE_GRANULARITY ?? (1~29)*total_of_CPU
In other words, if task is an interactive task, and time slice used is integral times of current preempt
interval (TIMESLICE_GRANULARITY) , and time slice remain is more then preempt interval, it arrive
the preempt-point, which current task yield CPU, enter one new schedule cycle.
For first question, I have a few confused yet.
As Steven said, if PREEMPT_ACTIVE is set, we cann't preempt current
task, because of
we can not wake up it later, however, the process of task switch will
save information
of the task context to task_struct (also thread_info), why we cann't
wake up it?
[added back the LKML since others might learn from this too]
On Tue, 11 Oct 2005, liyu wrote:
>
> For first question, I have a few confused yet.
> As Steven said, if PREEMPT_ACTIVE is set, we cann't preempt current task,
> because of
> we can not wake up it later, however, the process of task switch will
> save information
> of the task context to task_struct (also thread_info), why we cann't wake
> up it?
First let me corrent that statement. I said that if PREEMPT_ACTIVE is
set, we can't take the task off the run queue. I didn't say we can't
preempt that task, since that _is_ what is about to happen.
OK I worded it wrong. I shouldn't say we "can't" wake it up. What I
should have said is that we may not know to wake it up. You are right,
all the information is there to wake it up but the case might happen where
we just don't know to do it.
Here's some common code to look at.
add_wait_queue(q, wait);
set_current_state(TASK_UNINTERRUPTIBLE);
if (!some_event)
schedule();
set_current_state(TASK_RUNNING);
remove_wait_queue(q, wait);
This above code isn't directly from the kernel but the logic of it is all
over the place. So the task is going to wait for some event, and when
that event happens, it will wake up all the tasks that are on the wait
queue. Now what happens if the event happened before the
set_current_state(TASK_UNINTERRUPTIBLE)? Normally that would be OK
because of the check to see if some_event happened, and if it did then
don't call schedule.
Now back to that PREEMPT_ACTIVE check. If the above case happens, and then
the task is preempted before it set itself back to TASK_RUNNING, without
the PREEMPT_ACTIVE check in schedule, the process would be removed from
the task run queue. That means it is no longer in the queue to be
scheduled. But the event already happened that would have woken it back
up. So this task would forever stay in the TASK_UNINTERRUPTIBLE state and
never wake up. The PREEMPT_ACTIVE check is to allow the task to stay on
the run queue until it gets to a point that itself calls schedule. As the
above logic might allow (if the event has not happened yet).
So what determines what can be scheduled, is the fact that the task is on
the run queue, _not_ whether or not the task is in the TASK_RUNNING state.
At least with preemption enabled. Not being in TASK_RUNNING will take the
task off the run queue when that task calls schedule itself, not when it
is preempted.
Does this make more sense?
-- Steve
Steven Rostedt Wrote:
>[added back the LKML since others might learn from this too]
>
>On Tue, 11 Oct 2005, liyu wrote:
>
>
>
>>For first question, I have a few confused yet.
>>As Steven said, if PREEMPT_ACTIVE is set, we cann't preempt current task,
>>because of
>>we can not wake up it later, however, the process of task switch will
>>save information
>>of the task context to task_struct (also thread_info), why we cann't wake
>>up it?
>>
>>
>
>First let me corrent that statement. I said that if PREEMPT_ACTIVE is
>set, we can't take the task off the run queue. I didn't say we can't
>preempt that task, since that _is_ what is about to happen.
>
>OK I worded it wrong. I shouldn't say we "can't" wake it up. What I
>should have said is that we may not know to wake it up. You are right,
>all the information is there to wake it up but the case might happen where
>we just don't know to do it.
>
>Here's some common code to look at.
>
>add_wait_queue(q, wait);
>set_current_state(TASK_UNINTERRUPTIBLE);
>if (!some_event)
> schedule();
>set_current_state(TASK_RUNNING);
>remove_wait_queue(q, wait);
>
>
>This above code isn't directly from the kernel but the logic of it is all
>over the place. So the task is going to wait for some event, and when
>that event happens, it will wake up all the tasks that are on the wait
>queue. Now what happens if the event happened before the
>set_current_state(TASK_UNINTERRUPTIBLE)? Normally that would be OK
>because of the check to see if some_event happened, and if it did then
>don't call schedule.
>
>Now back to that PREEMPT_ACTIVE check. If the above case happens, and then
>the task is preempted before it set itself back to TASK_RUNNING, without
>the PREEMPT_ACTIVE check in schedule, the process would be removed from
>the task run queue. That means it is no longer in the queue to be
>scheduled. But the event already happened that would have woken it back
>up. So this task would forever stay in the TASK_UNINTERRUPTIBLE state and
>never wake up. The PREEMPT_ACTIVE check is to allow the task to stay on
>the run queue until it gets to a point that itself calls schedule. As the
>above logic might allow (if the event has not happened yet).
>
>So what determines what can be scheduled, is the fact that the task is on
>the run queue, _not_ whether or not the task is in the TASK_RUNNING state.
>At least with preemption enabled. Not being in TASK_RUNNING will take the
>task off the run queue when that task calls schedule itself, not when it
>is preempted.
>
>Does this make more sense?
>
>-- Steve
>
>
>
>
Hi, Steve:
Thanks for so detailed explain.
It seem I am not understand what is sleep and wakeup truly.
What's your mean of "in runqueue"? I think you mean the
task_struct is in one priority array (active or expired)
of one queue. the schedule() only can process task in runqueue.
In deactivate_task(), it will reset task_struct->array to NULL,
After call it, we can not wake up that task.
However, I read try_to_wake_up(), and found it can handle that case
which task_struct->array is NULL, it will be call activate_task()
to insert task to one runqueue. and default_wake_function() will
call try_to_wake_up(), so we still can wake up it.
I am confused again. this quesion is more interesting and more.
Wait for reply.
Good luck.
--liyu
On Tue, 11 Oct 2005, liyu wrote:
> Hi, Steve:
>
> Thanks for so detailed explain.
>
> It seem I am not understand what is sleep and wakeup truly.
>
> What's your mean of "in runqueue"? I think you mean the
> task_struct is in one priority array (active or expired)
> of one queue. the schedule() only can process task in runqueue.
> In deactivate_task(), it will reset task_struct->array to NULL,
> After call it, we can not wake up that task.
Correct. The active/expired arrays _are_ the run queue.
>
> However, I read try_to_wake_up(), and found it can handle that case
> which task_struct->array is NULL, it will be call activate_task()
> to insert task to one runqueue. and default_wake_function() will
> call try_to_wake_up(), so we still can wake up it.
Exactly! :-) try_to_wake_up _is_ what wakes up the task. Now the
problem is _who_ calls try_to_wake_up. My example is about some task that
initiates something that will happen and waits for it. Like something
writing to disk and waiting for the write to finish. It waits for an
interrupt or some service handler to do something. The problem is that
the logic that I showed, has to handle the case where the event happens
before it goes to sleep (calls schedule). Since the service provider is
the one that wakes it up, if the event happens before it goes to sleep and
the sevice provider already woke up the task (although it wasn't sleeping)
it wont wake it up again.
So, if the task is preempted in the TASK_UNINTERRUPTIBLE state and taken
off the run queue (active/expired arrays), and since the event had already
happened, _no_one_ will call try_to_wake_up on this task that is sleeping.
And the task will stay sleeping and never wake up.
>
> I am confused again. this quesion is more interesting and more.
You're getting closer to understanding. I can tell by your later
questions ;-)
>
> Wait for reply.
>
> Good luck.
>
>
> --liyu
>
-- Steve
Steven Rostedt Wrote:
>On Tue, 11 Oct 2005, liyu wrote:
>
>
>
>>Hi, Steve:
>>
>> Thanks for so detailed explain.
>>
>> It seem I am not understand what is sleep and wakeup truly.
>>
>> What's your mean of "in runqueue"? I think you mean the
>>task_struct is in one priority array (active or expired)
>>of one queue. the schedule() only can process task in runqueue.
>>In deactivate_task(), it will reset task_struct->array to NULL,
>>After call it, we can not wake up that task.
>>
>>
>
>Correct. The active/expired arrays _are_ the run queue.
>
>
>
>> However, I read try_to_wake_up(), and found it can handle that case
>>which task_struct->array is NULL, it will be call activate_task()
>>to insert task to one runqueue. and default_wake_function() will
>>call try_to_wake_up(), so we still can wake up it.
>>
>>
>
>Exactly! :-) try_to_wake_up _is_ what wakes up the task. Now the
>problem is _who_ calls try_to_wake_up. My example is about some task that
>initiates something that will happen and waits for it. Like something
>writing to disk and waiting for the write to finish. It waits for an
>interrupt or some service handler to do something. The problem is that
>the logic that I showed, has to handle the case where the event happens
>before it goes to sleep (calls schedule). Since the service provider is
>the one that wakes it up, if the event happens before it goes to sleep and
>the sevice provider already woke up the task (although it wasn't sleeping)
>it wont wake it up again.
>
>So, if the task is preempted in the TASK_UNINTERRUPTIBLE state and taken
>off the run queue (active/expired arrays), and since the event had already
>happened, _no_one_ will call try_to_wake_up on this task that is sleeping.
>And the task will stay sleeping and never wake up.
>
>
>
>> I am confused again. this quesion is more interesting and more.
>>
>>
>
>You're getting closer to understanding. I can tell by your later
>questions ;-)
>
>
>
>> Wait for reply.
>>
>> Good luck.
>>
>>
>>--liyu
>>
>>
>>
>
>-- Steve
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
hi, Steve:
Thanks, your words make this more sense. :)
The global process I understand is follow:
add_wait_queue(q, wait);
/*
* service handler is waking up current task now, it so soon!
* And the try_to_wake_up() will change task_struct->state to
TASK_RUNNING.
*/
set_current_state(TASK_UNINTERRUPTIBLE); /* reset task_struct->state
from TASK_RUNNING to TASK_UNINTERRUPTIBLE. */
if (!some_event) /* alreay wakeup, so some_event is true */
schedule();
/*
* preempt_schedule() is taking here!
* current task will sleep forever without PREEMPT_ACTIVE check!
because of it is removed
* from runqueue, and none will wakeup it (bring it back to runqueue).
*/
set_current_state(TASK_RUNNING);
remove_wait_queue(q, wait);
In fact, your first reply already is very clearly, but I read too
quickly to ignore something.
These code of only six lines imply so many secrets. All interesting came
from it.
Happy everyday.
-liyu
On Tue, 11 Oct 2005, liyu wrote:
>
> In fact, your first reply already is very clearly, but I read too
> quickly to ignore something.
>
> These code of only six lines imply so many secrets. All interesting came
> from it.
>
Hi liyu,
Looks like you understand it now. Good!
> Happy everyday.
>
Thank you, same to you. ;-)
-- Steve